Performance de

Performance und Optimierung

🌐 Diese Seite auf: English · Português · Español · Français · Deutsch

Der Schwerpunkt von eQuantic.UI liegt darauf, eine Single-Page-Application-Erfahrung (SPA) mit minimalem Mehraufwand zu liefern und dabei die Kraft von C# zu nutzen, um hochoptimierten Frontend-Code zu erzeugen.

🚀 Reconciliation und virtuelles DOM

Das virtuelle DOM-System wurde entworfen, um effizient zu sein und Zustandsänderungen vorauszusehen.

Diffing-Strategie (Keyed-LIS-Algorithmus)

Der Reconciliation-Algorithmus nutzt eine effiziente Keyed-Diffing-Strategie auf Basis des Algorithmus der längsten aufsteigenden Teilfolge (LIS).

• Die Key-Eigenschaft: Die Eigenschaft key identifiziert Elemente über Renderings hinweg. Elemente mit demselben Key werden wiederverwendet und an ihrem Platz aktualisiert.
• LIS-Optimierung: Werden Elemente neu geordnet, berechnet der Algorithmus die längste aufsteigende Teilfolge, um DOM-Bewegungen zu minimieren. Nur Elemente außerhalb der LIS müssen bewegt werden.
• Präfix-/Suffix-Optimierung: Gemeinsame Präfixe und Suffixe werden zuerst und ohne komplexes Diffing verarbeitet, was die Performance typischer Listenoperationen verbessert (hinten anfügen, vorn anfügen).
• Speichereffizienz: Unbewegte Elemente behalten ihren Browserzustand (Eingabefokus, Scrollposition usw.).

🧠 Ressourcenverwaltung (Speicherverwaltung)

Speicherlecks werden durch den klugen Einsatz schwacher Referenzen und automatischer Aufräumarbeit gemildert.

Verfolgung von Event-Listenern

Event-Listener werden mit WeakMap<HTMLElement, Map<string, EventHandler>> verfolgt.

• Schwache Referenzen: WeakMap erlaubt dem Garbage Collector, DOM-Elemente einzusammeln, wenn sie aus dem Baum entfernt werden, selbst wenn das Framework noch interne Referenzen auf ihre Handler hält.
• Automatisches Aufräumen: Beim Entfernen einer Komponente versucht der Reconciler, die Listener ausdrücklich abzuklemmen, aber die WeakMap dient als Sicherheitsnetz gegen Lecks in komplexen Lebenszyklen.

📦 Bündelung und Laden

Hybride Strategie mit Bun

Das SDK nutzt eine eingebettete Bun-Binary, um die endgültige Ausgabe zu verarbeiten.

• Build-Performance: Bun verarbeitet TS-/JS-Dateien bis zu zehnmal schneller als Werkzeuge auf Node.js-Basis.
• Tree-Shaking: Toter Code wird beim Build automatisch entfernt.
• Minifizierung: Skripte werden komprimiert ausgeliefert.

Atomares CSS, auf beiden Seiten gleich benannt

Ein Style ist ein abstrakter C#-Wert (BoxStyle, Layout-Props, Rollen), nie CSS. Der Web-Realisierer verwandelt jede Eigenschaft in eine deduplizierte ATOMARE Klasse, benannt nach einem Hash des Wertes (dieselbe FNV-Regel auf dem Server (StyleAtomizer) und im Browser (style-atomizer.ts)), sodass das Markup, das SSR schrieb, und der Baum, den der Client baut, eine Klasse für einen Style nennen, und die Hydration nichts umschreibt.

• Eine Regel je unterschiedlichem Wert: Hundert Karten mit einem Style teilen seine Klassen, statt hundert Inline-Style-Strings zu wiederholen.
• Kein Stylesheet zu holen: Der Server schreibt die Regeln, die eine Seite nutzt, in die Seite selbst (<style id="eq-atomic">), und der Browser fügt dieser Seite beim ersten Mal, wenn sein Baum eine Klasse braucht, die die Seite nicht hatte, eine Regel hinzu.
• Kein Layout-Sprung durch das Styling: Die Klassen, die der Server gerendert hat, sind die, die der Client behält.

Code-Splitting

• Chunks je Seite: Jede Seite ist ihr eigenes Modul, das der Boot bei der ersten Navigation dorthin importiert, und was zwei oder mehr Seiten teilen, ist ein Chunk, den bun einmal heraustrennt. Der Nutzer lädt nur, was für die aktuelle Route nötig ist.
• Lazy Loading: Komplexe Komponenten und Bibliotheken können bei Bedarf geladen werden.