Leistungsbericht

Was NSH-Apps kosten, gemessen. Wie NSH sie schnell hält und wie du die Performance deiner eigenen App misst, steht unter Performance.

#Baselines

Aus den eigenen Baselines von NSH (Apple Silicon, sofern nicht anders angegeben):

Szenario	Werte
Counter-App, headless (Debug)	Erster Frame ca. 0,5–0,65 ms (58 Ops / 49 Mount-Items); ein Tap ca. 0,15 ms
Counter-App, Mac Catalyst (Release)	Erster Frame ca. 1,05–1,15 ms (davon etwa 0,7 ms für das erstmalige Layout von 10 Texten mit CoreText); ein Tap ca. 0,12 ms
Gallery-Fotoliste, headless (Debug)	Erster Frame 653 Ops / 224 Nodes, ca. 2,7 ms
Scrollen der Fotoliste, Catalyst (Release)	Neues Binden einer Zeile beim langsamen Scrollen ca. 0,4 ms; ein ganzer Bildschirm mit ca. 32 Zeilen bei schnellem Fling 0,9–1,6 ms
Scrollen der Fotoliste, Android-Emulator (arm64, Release)	Neues Binden einer Zeile ca. 0,3–0,4 ms (JS ca. 60 µs)
Engine-Start (Release)	ca. 75–155 µs; die globalen APIs (fetch, URL, …) kosten bis zur ersten Verwendung nichts, danach ca. 90 µs
Hot Reload	ca. 120 ms vom Speichern einer Datei bis zur laufenden neuen Version; das Anwenden des Updates 0,2–0,5 ms

#Linux (GTK 4)

Gemessen auf einem Linux-Desktop (x86_64, 24 Threads, NVIDIA-GPU), Release-Builds, die Gallery in einem Fenster von 1896 × 1030 auf einem 120-Hz-Display, jeder Messwert automatisch erfasst von examples/gallery/tools/perf.py (nsh test --target linux --fps, eine Zeile pro Sekunde; die CPU-Last bezieht sich auf den gesamten Prozess, in Prozent eines Kerns). Frame p95 ist die Zeit des Main-Threads pro gezeichnetem Frame im 95. Perzentil: Unter 8,3 ms passt ein Frame in einen 120-Hz-Refresh.

#Animierte Demos

#Jede Seite

Jede Seite der Gallery, beim Öffnen und während der Test sie scrollt, in einem Fenster von 1200 × 800 auf einem 144-Hz-Display (derselben Maschine). NSH zeichnet nur dann einen Frame, wenn sich auf dem Bildschirm etwas ändert; FPS ist hier daher die Rate, solange sich etwas bewegt: ein Frame pro Median-Abstand zwischen gezeichneten Frames (perf.py, moving); bei den 144 des Displays folgt jeder Frame einer Animation oder eines Scrollvorgangs einen Refresh nach dem vorherigen. Über einem Refresh ist der Anteil der Frames, die länger als ein Refresh (6,9 ms) gedauert haben. GIF und WebP bei Images laufen mit ihren eigenen Bildraten (hier etwa 50 FPS), ebenso Video. Physics, Overlays und Menus sind kurz: In 1200 × 800 erreicht ein Scrollvorgang ihr Ende innerhalb weniger Frames, daher werden sie in einem Fenster von 900 × 500 gemessen, in dem sie Platz zum Scrollen haben.

#Speicher

Im Ruhezustand, 3 s nach dem Start (Release-Runner, ein Fenster von 480 × 640). Private ist der Speicher, den allein der Prozess besitzt (USS); Resident addiert die Seiten der Shared Libraries (GTK, der GPU-Treiber), die sich jede GTK-App auf der Maschine teilt:

Das erneute Aufrufen einer Seite benötigt keinen zusätzlichen Speicher; beim ersten Besuch einer Seite wächst der Prozess um das, was er bewusst cacht (dekodierte Bilder, auf 128 MB begrenzt), und um die Bibliotheken, die erst bei der ersten Verwendung geladen werden (WebKitGTK für Web Views).

#App-Größe

Eine Hello-World-App, erzeugt von nsh init mit jedem Template, und zwei Apps, die Menschen tatsächlich nutzen, so wie nsh package --target linux sie für x86_64 baut. Der Runner ist die einzige ausführbare Datei der App; das Archiv ist das .tar.gz, als das sie ausgeliefert wird. Die Hello Worlds werden mit Link-Time-Optimierung gebaut und gestrippt (CARGO_PROFILE_RELEASE_LTO=fat, CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1, CARGO_PROFILE_RELEASE_STRIP=true):

Die TSX-Runner enthalten die QuickJS-Runtime, die nativen Module und den Renderer; der eigene Code einer App ist ihr Bundle neben dem Runner, bei einem Hello World unter 1 KB.

Was diese Zahlen ausmacht:

• Der Renderer: Unter dem NVIDIA-Treiber zeichnet NSH mit dem GL-Renderer von GSK, dessen Frames dort nur einen Bruchteil dessen kosten, was der Vulkan- Renderer braucht (die Animations-Demo: ca. 1 ms Zeichenzeit pro Frame statt ca. 9,5 ms). GSK_RENDERER hat weiterhin das letzte Wort.
• Canvas-Rasters: Jeder Canvas wird einmal in 256-px-Kacheln gerastert, die auf der GPU bleiben. Ein animierter Wert zeichnet nur den Bereich neu, den die Operationen abdecken, die ihn lesen, über den beibehaltenen Pixeln des statischen Teils der Zeichnung; ein Canvas außerhalb des Sichtbereichs wartet, bis er in den Sichtbereich scrollt.
• Pfade einmal beiseitegelegt: fillRect und fillText nach einem langen Pfad lassen ihn an Ort und Stelle, bis er erneut verwendet wird (eine Linie mit 400 Punkten, dann 240 Balken: 0,63 ms).

#macOS (AppKit)

Gemessen auf einem MacBook Pro (Apple M3, 24 GB) mit dem integrierten 120-Hz-ProMotion-Display, Release-Builds, die Gallery in einem Fenster von 1200 × 800, jeder Messwert automatisch erfasst von examples/gallery/tools/perf.py (nsh test --target macos --fps, eine Zeile pro Sekunde; die CPU-Last bezieht sich auf den gesamten Prozess, in Prozent eines Kerns, die GPU auf ihren Anteil an der GPU). Die Phasen sind die des Main-Threads pro Frame: tick (die nativen Animationen des Display Links) und canvas (das Abspielen von Zeichnungen).

#Animierte Demos

Bei Stocks beträgt die Main-Thread-Zeit eines Frames ca. 1,6 ms für Ticks, wovon ca. 0,45 ms auf das Abspielen der animierten Teile der Canvases entfallen; Core Animation zeichnet den Rest jedes Canvas auf eigenen Threads.

#Jede Seite

Jede Seite der Gallery, beim Öffnen und während der Test sie scrollt, im selben Fenster von 1200 × 800. Wie unter Linux ist FPS die Rate, solange sich etwas bewegt (ein Frame pro Median-Abstand zwischen gezeichneten Frames); bei den 120 des Displays folgt jeder Frame einer Animation oder eines Scrollvorgangs einen Refresh nach dem vorherigen. Über einem Refresh ist der Anteil der Frames, die länger als ein Refresh (8,3 ms) gedauert haben. Eine ruhende Seite zeichnet keinen Frame und verbraucht 2–5 % CPU. GIF und WebP bei Images laufen in Core Animation und Video in AVFoundation, jeweils mit ihren eigenen Bildraten.

#Speicher

Im Ruhezustand, 3 s nach dem Start (Release-Runner). Footprint ist der Speicher, den macOS dem Prozess anrechnet (das, was die Aktivitätsanzeige zeigt); Resident addiert die Seiten der Shared Libraries des Systems:

Während der Tour durch die Gallery belegt der Prozess bis zur Canvas-Seite 84–230 MB und ab der Text-View-Seite ca. 350–360 MB, bedingt durch das, was er bewusst cacht (dekodierte Bilder, auf 128 MB begrenzt; die Dokumente der Text-View-Seite), und durch die Frameworks, die er erst bei der ersten Verwendung lädt (WebKit für Web Views); die Rasters der Canvas-Seite, bis zu ca. 310 MB, wenn alle drei Canvases auf dem Bildschirm sind, verschwinden, wenn die Seite geschlossen wird.

#App-Größe

Die Hello-World-Apps, die nsh init mit jeder Vorlage erzeugt, so wie nsh package --target macos sie für Apple Silicon (arm64) baut, mit Link-Time-Optimierung und gestrippt wie unter Linux, sowie die beiden obigen Apps in der für Apple Silicon ausgelieferten Form. Die ausführbare Datei ist der Runner im .app; das Zip ist das komprimierte .app (ditto -c -k):

Das machen diese Zahlen möglich:

• Frames nur bei Änderungen: Der Display Link tickt, solange eine native Animation läuft, und endet mit ihr; eine Animation endet mit ihrer Seite (das Löschen ihrer View beendet ihre Keyframes, eine Schleife endet in der cleanup ihrer Komponente).
• Canvases dort gezeichnet, wo es am wenigsten kostet: Ein Canvas, der oft neu gezeichnet wird (eine Animation, Live-Daten), zeichnet auf den Threads von Core Animation (drawsAsynchronously), was den Main-Thread freihält; einer, der nur gelegentlich neu gezeichnet wird, zeichnet sofort, ohne den Grafikspeicher, den asynchrones Zeichnen belegt. Ein animierter Wert zeichnet nur den Bereich neu, den die Operationen abdecken, die ihn lesen.
• Statische Canvas-Teile bleiben erhalten: Sobald eine Zeichnung unverändert bleibt, wird ein langer Teil vor der ersten animierten Operation als Layer behalten; jeder Frame zeichnet diesen Layer und spielt nur den animierten Rest erneut ab, sofort auf dem Main-Thread (die Gauge, die Uhr und die Punktmatrix der Canvas-Seite: keine GPU-Arbeit und halb so viel Speicher).
• Inhalte werden gezeichnet, wenn sie sich ändern: Texte und Canvases zeichnen in eigene Layer, erneut, wenn sich ihr Inhalt oder ihre Größe ändert, nicht wenn sie bewegt oder gescrollt werden.

#Windows (Win32, Direct2D)

Gemessen auf einem Windows-11-Desktop (Intel Core i7-13700KF, 32 GB, NVIDIA GeForce RTX 3060 Ti) mit einem 4K-144-Hz-Display bei 150 %, Release-Builds, die Gallery in einem Fenster von 1200 × 800 (1800 × 1200 Pixel), jede Messung automatisch erfasst von examples/gallery/tools/perf.py (nsh test --target windows --fps, eine Zeile pro Sekunde; CPU ist der gesamte Prozess, in Prozent eines Kerns). Die Phasen beziehen sich auf den Main-Thread pro Frame: paint (Direct2D zeichnet das Fenster) und, darin enthalten, canvas (Aufzeichnen und Abspielen von Zeichnungen).

#Animierte Demos

Stocks committet 16–17 Mal pro Sekunde, jeweils in bis zu 2,1 ms JS und 1,7 ms Core auf dem Engine-Thread (p95).

#Jede Seite

Jede Seite der Gallery, beim Öffnen und während der Test sie scrollt, im selben Fenster von 1200 × 800. Wie unter Linux und macOS ist FPS die Rate, während sich etwas bewegt (ein Frame pro Median der Abstände zwischen gezeichneten Frames); bei den 144 des Displays kommt jeder Frame einer Animation oder eines Scrollvorgangs einen Refresh nach dem letzten. Over one refresh ist der Anteil der Frames, die länger als ein Refresh (6,9 ms) gebraucht haben. Eine ruhende Seite zeichnet keinen Frame und verbraucht 0–2 % CPU. Die GIF- und WebP-Bilder der Images-Seite spielen mit ihren eigenen Frameraten (hier etwa 40 FPS). Physics, Overlays, Menus und Storage werden in einem Fenster von 900 × 500 gemessen, in dem sie Platz zum Scrollen haben.

#Arbeitsspeicher

In Ruhe, 3 s nach dem Start (Release-Runner, ein Fenster von 1200 × 800). Private Working Set ist der Speicher, den der Prozess allein nutzt (die Spalte „Arbeitsspeicher“ des Task-Managers); Private Bytes der Speicher, den er committet hat; Working Set enthält zusätzlich die Seiten der Systembibliotheken, die er mit anderen Prozessen teilt (Direct3D, Direct2D, DirectWrite, der GPU-Treiber):

Während der Tour durch die Gallery liegt das Working Set bei ~108–115 MB auf Stocks, ~230 MB ab der Canvas-Seite, ~320–340 MB ab der Text-View-Seite und ~390–405 MB, sobald Web and video WebView2 geöffnet hat (dessen Seiten in eigenen WebView2-Prozessen laufen), einschließlich dessen, was bewusst gecacht wird (decodierte Bilder, auf 128 MB begrenzt; die Dokumente der Text-View-Seite).

#App-Größe

Die Hello-World-Apps, die nsh init mit jeder Vorlage erzeugt, so wie nsh package --target windows sie für x86_64 baut (die Rust-Runner mit Link-Time-Optimierung und gestrippt, wie unter Linux). Die ausführbare Datei ist das <Name>.exe der App; das Zip ist das .zip, das neben ihrem Verzeichnis geschrieben wird:

Das machen diese Zahlen möglich:

• Frames nur bei Änderungen, nur dort gezeichnet, wo sie sich geändert haben: Der vom Compositor getaktete Ticker läuft, solange eine native Animation, ein Übergang oder ein Frame-Callback läuft. Ein Frame zeichnet die Bereiche der geänderten Views (dort, wo sie waren, und dort, wo sie sind) über die Pixel, die das Fenster behält, und übergibt nur diese an den Compositor (Stocks: ~34 Views pro Frame).
• Canvases zeichnen ihren animierten Teil auf: Eine Zeichnung wird als Direct2D-Command-Lists aufgezeichnet, vektorbasiert und scharf bei jeder Skalierung. Ändert sich ein animierter Wert, werden nur die Operationen ab der ersten, die einen animierten Wert liest, erneut aufgezeichnet; was davor liegt, bleibt erhalten (Stocks: ~26 ms Aufzeichnung pro Sekunde für 22 pulsierende Sparklines und das Chart).
• Nur das Sichtbare wird gezeichnet: Die Kinder einer Scroll-View oder einer Clipping-View, die außer Sicht liegen, werden aus dem Frame ausgelassen, und Views ohne eigenen Inhalt zeichnen nicht mehr als ihren Hintergrund und Rand.

#iOS (UIKit)

Gemessen im iOS-Simulator (ein iPhone 18 Pro Max, auf dem oben genannten MacBook Pro), Release-Builds, mit derselben Tour (perf.py --target ios: nsh test --target ios --fps, die Berührungen eines Fingers, wie UIKit sie erhält). Der Simulator stellt mit 60 Hz dar; auf einem iPhone mit ProMotion-Display laufen die Display Links von NSH mit den 120 Hz des Displays (Apps, die nsh package baut, und der Entwicklungs-Host fordern dies mit CADisableMinimumFrameDurationOnPhone an). Die Phasen sind tick (native Animationen), drain (Anwenden der Batches der Engine) und scroll (was auf eine Scroll-View folgt: Listen, Sticky Cells, gebundene Werte).

FPS ist die Rate, während sich etwas bewegt, wie oben: Bei den 60 des Simulators kommt jeder Frame einen Refresh nach dem letzten. Jede Seite, auf der sich nichts bewegt, zeichnet keinen Frame und verbraucht in Ruhe 1–2 % CPU. Der Prozess belegt 40 MB auf der Startseite der Gallery und ~180 MB nach der gesamten Tour (bewusst gecachte Bilder, die Dokumente der Text-View-Seite).

Auf einem iPhone 17 Pro (ProMotion, 120 Hz), mit dem Entwicklungs-Host und einer Demo auf dem Bildschirm, zeichnen die animierten Seiten in jedem Refresh:

Stocks committet 20 Mal pro Sekunde (ein Tick alle 50 ms), jeweils in 1,5 ms JS und 1,4 ms Core auf dem Engine-Thread (p95 2,2 und 2,0 ms), der zu 4–6 % der Zeit ausgelastet ist.

#Eine App messen

Um eine App auf dieselbe Weise zu messen, führen Sie ihre Tests oder Schritte mit --fps und -v auf --target linux, macos, windows oder ios aus:

cargo build --release -p nsh-cli
python3 examples/gallery/tools/perf.py --target macos --only Stocks,Canvas   # the gallery, page by page
echo 'await app.wait(5000)' | nsh -v test App.tsx --target linux --fps        # any app