Rapport de performance

Ce que coûtent les apps NSH, mesuré. Pour savoir comment NSH les garde rapides et comment mesurer votre propre app, consultez Performance.

#Valeurs de référence

Issues des mesures de référence de NSH (Apple silicon, sauf mention contraire) :

#Linux (GTK 4)

Mesuré sur un poste Linux (x86_64, 24 threads, GPU NVIDIA), en builds release, avec la galerie dans une fenêtre de 1896 × 1030 sur un écran 120 Hz, chaque relevé étant pris automatiquement par examples/gallery/tools/perf.py (nsh test --target linux --fps, une ligne par seconde ; le CPU est celui du processus entier, en pourcentage d’un cœur). Frame p95 est le temps du thread principal par frame dessinée au 95e centile : sous 8,3 ms, une frame tient dans un rafraîchissement à 120 Hz.

#Démos animées

#Chaque page

Chaque page de la galerie, à son ouverture et pendant que le test la fait défiler, dans une fenêtre de 1200 × 800 sur un écran 144 Hz (la même machine). NSH ne dessine une frame que lorsque quelque chose change à l’écran ; FPS désigne donc ici la cadence pendant qu’un élément bouge : une frame par écart médian entre les frames dessinées (perf.py, moving) ; à 144 Hz, chaque frame d’une animation ou d’un défilement arrive un rafraîchissement après la précédente. Au-delà d’un rafraîchissement est la part des frames qui ont pris plus longtemps qu’un rafraîchissement (6,9 ms). Les GIF et WebP d’Images sont lus à leur propre cadence (environ 50 FPS ici), de même que la vidéo. Physics, Overlays et Menus sont courtes : dans une fenêtre de 1200 × 800, un défilement atteint leur fin en quelques frames ; elles sont donc mesurées dans une fenêtre de 900 × 500, où elles ont de la place pour défiler.

#Mémoire

Au repos, 3 s après le démarrage (runners release, fenêtre de 480 × 640). Private est la mémoire que le processus possède à lui seul (USS) ; resident y ajoute les pages des bibliothèques partagées (GTK, le pilote GPU), que toutes les apps GTK de la machine partagent :

Revisiter une page n’ajoute aucune mémoire ; la première visite d’une page fait croître le processus de ce qu’il met volontairement en cache (images décodées, plafonnées à 128 Mo) et des bibliothèques qu’il charge à la première utilisation (WebKitGTK pour les web views).

#Taille des apps

Une app hello world créée par nsh init avec chaque template, et deux apps utilisées au quotidien, telles que nsh package --target linux les construit pour x86_64. Le runner est l’unique exécutable de l’app ; l’archive est le .tar.gz sous lequel elle est distribuée. Les hello worlds sont construits avec l’optimisation à l’édition de liens (link-time optimization) et strippés (CARGO_PROFILE_RELEASE_LTO=fat, CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1, CARGO_PROFILE_RELEASE_STRIP=true) :

Les runners TSX contiennent le runtime QuickJS, les modules natifs et le moteur de rendu ; le code propre à une app est son bundle, placé à côté du runner, de moins de 1 Ko pour un hello world.

Ce qui produit ces chiffres :

• Le moteur de rendu : avec le pilote de NVIDIA, NSH dessine avec le moteur de rendu GL de GSK, dont les frames coûtent une fraction de celles du moteur de rendu Vulkan dans ce cas (la démo Animations : ~1 ms de dessin par frame au lieu de ~9,5 ms). GSK_RENDERER garde toutefois la main sur le choix.
• Rasterisation des canvas : chaque canvas est rasterisé une seule fois en tuiles de 256 px conservées sur le GPU. Une valeur animée ne redessine que la zone couverte par les opérations qui la lisent, par-dessus les pixels conservés de la partie statique du dessin ; un canvas hors de vue attend d’entrer dans la zone visible par défilement.
• Chemins mis de côté une seule fois : fillRect et fillText après un long chemin le laissent en place jusqu’à sa prochaine utilisation (une ligne de 400 points puis 240 barres : 0,63 ms).

#macOS (AppKit)

Mesuré sur un MacBook Pro (Apple M3, 24 Go) avec son écran ProMotion 120 Hz intégré, en builds release, avec la galerie dans une fenêtre de 1200 × 800, chaque relevé étant pris automatiquement par examples/gallery/tools/perf.py (nsh test --target macos --fps, une ligne par seconde ; le CPU est celui du processus entier, en pourcentage d’un cœur, et le GPU sa part du GPU). Les phases sont celles du thread principal par frame : tick (les animations natives du display link) et canvas (la relecture des dessins).

#Démos animées

Sur Stocks, le temps du thread principal par frame est d’environ 1,6 ms de ticks, dont ~0,45 ms pour rejouer les parties animées des canvas ; Core Animation dessine le reste de chaque canvas sur ses propres threads.

#Chaque page

Chaque page de la galerie, à son ouverture et pendant que le test la fait défiler, dans la même fenêtre de 1200 × 800. Comme sur Linux, FPS désigne la cadence pendant qu’un élément bouge (une frame par écart médian entre les frames dessinées) ; à 120 Hz, chaque frame d’une animation ou d’un défilement arrive un rafraîchissement après la précédente. Au-delà d’un rafraîchissement est la part des frames qui ont pris plus longtemps qu’un rafraîchissement (8,3 ms). Une page au repos ne dessine aucune frame et utilise 2–5 % de CPU. Les GIF et WebP d’Images sont lus dans Core Animation et la vidéo dans AVFoundation, à leur propre cadence.

#Mémoire

Au repos, 3 s après le démarrage (runners release). Footprint est la mémoire que macOS impute au processus (ce qu’affiche Activity Monitor) ; resident y ajoute les pages des bibliothèques partagées du système :

Au fil de la visite de la galerie, le processus occupe 84–230 Mo jusqu’à la page Canvas, puis ~350–360 Mo à partir de la page Text View, avec ce qu’il met volontairement en cache (images décodées, plafonnées à 128 Mo ; les documents de la page Text View) et les frameworks qu’il charge à la première utilisation (WebKit pour les web views) ; les rasters de la page Canvas, jusqu’à ~310 Mo avec les trois canvas à l’écran, sont libérés à la fermeture de la page.

#Taille des applications

Les applications hello world créées par nsh init avec chaque modèle, telles que nsh package --target macos les construit pour Apple silicon (arm64), avec l’optimisation à l’édition de liens (LTO) et sans symboles comme sous Linux, ainsi que les deux applications ci-dessus telles qu’elles sont livrées pour Apple silicon. L’exécutable est le runner à l’intérieur de .app ; le zip est .app compressé (ditto -c -k) :

Ce qui explique ces chiffres :

• Des frames uniquement pour les changements : le display link se déclenche tant qu’une animation native s’exécute et s’arrête avec elle ; une animation s’arrête avec sa page (la suppression de sa vue met fin à ses keyframes, une boucle s’arrête dans le cleanup de son composant).
• Des canvas dessinés là où ils coûtent le moins : un canvas qui se repeint souvent (une animation, des données en direct) dessine sur les threads de Core Animation (drawsAsynchronously), ce qui laisse le thread principal libre ; un canvas redessiné de temps en temps dessine immédiatement, sans la mémoire graphique que retient le dessin asynchrone. Une valeur animée ne redessine que la zone que couvrent les opérations qui la lisent.
• Parties statiques du canvas conservées : dès qu’un dessin reste inchangé, une longue partie située avant sa première opération animée est conservée sous forme de calque ; chaque frame dessine ce calque et ne rejoue que le reste animé, immédiatement sur le thread principal (la jauge, l’horloge et la matrice de points de la page Canvas : aucun travail GPU et moitié moins de mémoire).
• Contenu dessiné quand il change : les textes et les canvas se dessinent dans des calques qui leur sont propres, de nouveau quand leur contenu ou leur taille change, et non quand ils se déplacent ou défilent.

#Windows (Win32, Direct2D)

Mesures effectuées sur un ordinateur de bureau Windows 11 (Intel Core i7-13700KF, 32 Go, NVIDIA GeForce RTX 3060 Ti) avec un écran 4K 144 Hz à 150 %, en builds release, la galerie dans une fenêtre de 1200 × 800 (1800 × 1200 pixels), chaque relevé étant pris automatiquement par examples/gallery/tools/perf.py (nsh test --target windows --fps, une ligne par seconde ; le CPU est celui du processus entier, en pourcentage d’un cœur). Les phases sont celles du thread principal par frame : paint (Direct2D dessinant la fenêtre) et, à l’intérieur, canvas (enregistrement et rejeu des dessins).

#Démos animées

Stocks effectue 16 à 17 commits par seconde, chacun en 2,1 ms de JS au plus et 1,7 ms du cœur sur le thread du moteur (p95).

#Chaque page

Chaque page de la galerie, à son ouverture et pendant que le test la fait défiler, dans la même fenêtre de 1200 × 800. Comme sous Linux et macOS, FPS est la cadence pendant qu’un élément bouge (une frame par écart médian entre les frames dessinées) ; à 144 Hz, celle de l’écran, chaque frame d’une animation ou d’un défilement arrive un rafraîchissement après la précédente. Au-delà d’un rafraîchissement est la part des frames qui ont pris plus longtemps qu’un rafraîchissement (6,9 ms). Une page au repos ne dessine aucune frame et utilise 0 à 2 % de CPU. Les GIF et WebP de la page Images sont lus à leur propre cadence (environ 40 FPS ici). Physics, Overlays, Menus et Storage sont mesurées dans une fenêtre de 900 × 500, où elles ont de la place pour défiler.

#Mémoire

Au repos, 3 s après le démarrage (runners release, fenêtre de 1200 × 800). Le working set privé est la mémoire que le processus utilise à lui seul (colonne Mémoire du Gestionnaire des tâches) ; les octets privés ce qu’il a validé (committed) ; le working set ajoute les pages des bibliothèques système qu’il partage avec d’autres processus (Direct3D, Direct2D, DirectWrite, le pilote GPU) :

Au fil du parcours de la galerie, le working set atteint ~108–115 Mo sur Stocks, ~230 Mo à partir de la page Canvas, ~320–340 Mo à partir de la page Text View et ~390–405 Mo une fois que Web and video a ouvert WebView2 (dont les pages s’exécutent dans les processus propres à WebView2), avec ce qu’elle met en cache volontairement (images décodées, plafonnées à 128 Mo ; les documents de la page Text View).

#Taille des applications

Les applications hello world créées par nsh init avec chaque modèle, telles que nsh package --target windows les construit pour x86_64 (les runners Rust avec optimisation à l’édition de liens et sans symboles, comme sous Linux). L’exécutable est <Name>.exe de l’application ; le zip est .zip écrit à côté de son répertoire :

Ce qui explique ces chiffres :

• Des frames uniquement pour les changements, dessinées uniquement là où ils ont eu lieu : le ticker cadencé par le compositeur tourne tant qu’une animation native, une transition ou un callback de frame s’exécute. Une frame dessine les zones des vues qui ont changé (là où elles étaient et là où elles sont), sur les pixels que la fenêtre conserve, et ne présente qu’elles au compositeur (Stocks : ~34 vues par frame).
• Les canvas enregistrent leur partie animée : un dessin est enregistré sous forme de listes de commandes Direct2D, vectorielles et nettes à toute échelle. Quand une valeur animée change, seules les opérations à partir de la première qui lit une valeur animée sont enregistrées de nouveau ; ce qui précède est conservé (Stocks : ~26 ms d’enregistrement par seconde pour 22 sparklines pulsantes et le graphique).
• Seul ce qui est visible est dessiné : les enfants d’une vue à défilement ou d’une vue avec découpage (clipping) qui se trouvent hors de vue sont exclus de la frame, et les vues sans contenu propre ne dessinent pas plus que leur arrière-plan et leur bordure.

#iOS (UIKit)

Mesures effectuées dans le simulateur iOS (un iPhone 18 Pro Max, sur le MacBook Pro ci-dessus), en builds release, avec le même parcours (perf.py --target ios : nsh test --target ios --fps, les touches d’un doigt telles que UIKit les reçoit). Le simulateur présente à 60 Hz ; sur un iPhone avec un écran ProMotion, les display links de NSH tournent à 120 Hz, la fréquence de l’écran (les applications que nsh package construit et l’hôte de développement la demandent avec CADisableMinimumFrameDurationOnPhone). Les phases sont tick (animations natives), drain (application des lots du moteur) et scroll (ce qui suit une vue à défilement : listes, cellules sticky, valeurs liées).

FPS est la cadence pendant qu’un élément bouge, comme ci-dessus : à 60 Hz, celle du simulateur, chaque frame arrive un rafraîchissement après la précédente. Toute page où rien ne bouge ne dessine aucune frame et utilise 1 à 2 % de CPU au repos. Le processus occupe 40 Mo sur la page d’accueil de la galerie et ~180 Mo après l’ensemble du parcours (images mises en cache volontairement, documents de la page Text View).

Sur un iPhone 17 Pro (ProMotion, 120 Hz), avec l’hôte de développement et une démo à l’écran, les pages animées dessinent à chaque rafraîchissement :

Stocks effectue 20 commits par seconde (un tick toutes les 50 ms), chacun en 1,5 ms de JS et 1,4 ms du cœur sur le thread du moteur (p95 : 2,2 et 2,0 ms), lequel est occupé 4 à 6 % du temps.

#Mesurer une application

Pour mesurer une application de la même façon, exécutez ses tests ou ses étapes avec --fps et -v sur --target linux, macos, windows ou ios :

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