Informe de rendimiento

Lo que cuestan las apps de NSH, medido. Cómo NSH las mantiene rápidas y cómo medir tu propia app se explica en Rendimiento.

#Valores de referencia

De las mediciones base del propio NSH (Apple silicon salvo indicación contraria):

Escenario	Cifras
App contador, headless (debug)	Primer frame ~0.5–0.65 ms (58 ops / 49 mount items); un toque ~0.15 ms
App contador, Mac Catalyst (release)	Primer frame ~1.05–1.15 ms (unos 0.7 ms se dedican a maquetar 10 textos con CoreText por primera vez); un toque ~0.12 ms
Lista de fotos de Gallery, headless (debug)	Primer frame 653 ops / 224 nodos, ~2.7 ms
Scroll de la lista de fotos, Catalyst (release)	Revincular una fila mientras se hace scroll lento ~0.4 ms; una pantalla completa de ~32 filas en un fling rápido 0.9–1.6 ms
Scroll de la lista de fotos, emulador de Android (arm64, release)	Revincular una fila ~0.3–0.4 ms (JS ~60 µs)
Arranque del motor (release)	~75–155 µs; las APIs globales (fetch, URL, …) no cuestan nada hasta el primer uso, y luego ~90 µs
Hot reload	~120 ms desde que se guarda un archivo hasta que la nueva versión está en ejecución; aplicar la actualización 0.2–0.5 ms

#Linux (GTK 4)

Medido en un escritorio Linux (x86_64, 24 hilos, GPU NVIDIA), con builds release, la galería en una ventana de 1896 × 1030 en una pantalla de 120 Hz, con cada lectura tomada automáticamente por examples/gallery/tools/perf.py (nsh test --target linux --fps, una línea por segundo; la CPU corresponde al proceso completo, en porcentaje de un núcleo). Frame p95 es el tiempo del hilo principal por frame dibujado en el percentil 95: por debajo de 8.3 ms, un frame cabe en un refresco de 120 Hz.

#Demos animadas

#Todas las páginas

Todas las páginas de la galería, al abrirse y mientras la prueba hace scroll en ellas, en una ventana de 1200 × 800 en una pantalla de 144 Hz (la misma máquina). NSH dibuja un frame solo cuando algo cambia en pantalla, así que FPS aquí es la tasa mientras algo se mueve: un frame por cada intervalo mediano entre frames dibujados (moving de perf.py); a los 144 de la pantalla, cada frame de una animación o de un scroll llega un refresco después del anterior. Sobre un refresco es la proporción de frames que tardaron más que un refresco (6.9 ms). Los GIF y WebP de Images se reproducen a sus propias tasas de frames (unos 50 FPS aquí), igual que el video. Physics, Overlays y Menus son cortas: en 1200 × 800 un scroll llega a su final en pocos frames, por lo que se miden en una ventana de 900 × 500, donde tienen espacio para hacer scroll.

#Memoria

En reposo, 3 s después del arranque (runners release, ventana de 480 × 640). Private es la memoria que posee únicamente el proceso (USS); resident suma las páginas de las bibliotecas compartidas (GTK, el controlador de la GPU), que comparten todas las apps GTK de la máquina:

Volver a visitar una página no añade memoria; la primera visita a una página hace crecer el proceso por lo que almacena en caché a propósito (imágenes decodificadas, con un límite de 128 MB) y por las bibliotecas que carga en el primer uso (WebKitGTK para las vistas web).

#Tamaño de la app

Una app hello world creada por nsh init con cada plantilla, y dos apps que la gente usa, tal como nsh package --target linux las compila para x86_64. El runner es el único ejecutable de la app; el archive es el .tar.gz con el que se distribuye. Los hello worlds se compilan con link-time optimization y se les quitan los símbolos (CARGO_PROFILE_RELEASE_LTO=fat, CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1, CARGO_PROFILE_RELEASE_STRIP=true):

Los runners de TSX contienen el runtime de QuickJS, los módulos nativos y el renderer; el código propio de una app es su bundle, junto al runner, de menos de 1 KB para un hello world.

Qué hace posibles estas cifras:

• El renderer: con el controlador de NVIDIA, NSH dibuja con el renderer GL de GSK, cuyos frames cuestan una fracción de los del renderer Vulkan en ese caso (la demo Animations: ~1 ms de dibujo por frame en lugar de ~9.5 ms). GSK_RENDERER sigue teniendo la última palabra.
• Rasterizados del canvas: cada canvas se rasteriza una vez en tiles de 256 px que se mantienen en la GPU. Un valor animado vuelve a dibujar solo el área que cubren las operaciones que lo leen, sobre los píxeles conservados de la parte estática del dibujo; un canvas fuera de la vista espera hasta que entra en pantalla con el scroll.
• Paths reservados una sola vez: fillRect y fillText después de un path largo lo dejan donde está hasta que se vuelve a usar (una línea de 400 puntos y luego 240 barras: 0.63 ms).

#macOS (AppKit)

Medido en un MacBook Pro (Apple M3, 24 GB) con su pantalla ProMotion integrada de 120 Hz, con builds release, la galería en una ventana de 1200 × 800, con cada lectura tomada automáticamente por examples/gallery/tools/perf.py (nsh test --target macos --fps, una línea por segundo; la CPU corresponde al proceso completo, en porcentaje de un núcleo, y la GPU a su parte de la GPU). Las fases son las del hilo principal por frame: tick (las animaciones nativas del display link) y canvas (la reproducción de los dibujos).

#Demos animadas

En Stocks, el tiempo del hilo principal por frame es de ~1.6 ms de ticks, de los cuales ~0.45 ms reproducen las partes animadas de los canvas; Core Animation dibuja el resto de cada canvas en sus propios hilos.

#Todas las páginas

Todas las páginas de la galería, al abrirse y mientras la prueba hace scroll en ellas, en la misma ventana de 1200 × 800. Como en Linux, FPS es la tasa mientras algo se mueve (un frame por cada intervalo mediano entre frames dibujados); a los 120 de la pantalla, cada frame de una animación o de un scroll llega un refresco después del anterior. Sobre un refresco es la proporción de frames que tardaron más que un refresco (8.3 ms). Una página en reposo no dibuja ningún frame y usa un 2–5% de CPU. Los GIF y WebP de Images se reproducen en Core Animation y el video en AVFoundation, a sus propias tasas de frames.

#Memoria

En reposo, 3 s después del arranque (runners release). Footprint es la memoria que macOS carga al proceso (lo que muestra el Monitor de Actividad); resident suma las páginas de las bibliotecas compartidas del sistema:

A lo largo del recorrido por la galería, el proceso ocupa 84–230 MB hasta la página Canvas y ~350–360 MB a partir de la página Text View, con lo que almacena en caché a propósito (imágenes decodificadas, con un límite de 128 MB; los documentos de la página Text View) y los frameworks que carga en el primer uso (WebKit para las vistas web); los rasterizados de la página Canvas, de hasta ~310 MB con los tres canvas en pantalla, se liberan cuando la página se cierra.

#Tamaño de la app

Las apps hello world que crea nsh init con cada plantilla, tal como las compila nsh package --target macos para Apple silicon (arm64), con optimización en tiempo de enlazado y sin símbolos, como en Linux, y las dos apps anteriores tal como se distribuyen para Apple silicon. El ejecutable es el runner dentro de .app; el zip es el .app comprimido (ditto -c -k):

Qué hace posibles estas cifras:

• Fotogramas solo para los cambios: el display link se activa mientras se ejecuta una animación nativa y se detiene con ella; una animación se detiene con su página (la eliminación de su vista termina sus fotogramas clave, un bucle se detiene en el cleanup de su componente).
• Canvas dibujados donde cuestan menos: un canvas que se pinta con frecuencia (una animación, datos en vivo) se dibuja en los hilos de Core Animation (drawsAsynchronously), lo que mantiene libre el hilo principal; uno que se redibuja de vez en cuando se dibuja de inmediato, sin la memoria gráfica que retiene el dibujo asíncrono. Un valor animado redibuja solo el área que cubren las operaciones que lo leen.
• Partes estáticas del canvas conservadas: cuando un dibujo permanece sin cambios, una parte larga anterior a su primera operación animada se conserva como una capa; cada fotograma dibuja esa capa y reproduce solo el resto animado, de inmediato en el hilo principal (el indicador, el reloj y la matriz de puntos de la página Canvas: sin trabajo de GPU y con la mitad de memoria).
• Contenido dibujado cuando cambia: los textos y los canvas se dibujan en capas propias, de nuevo cuando cambia su contenido o su tamaño, no cuando se mueven o se desplazan.

#Windows (Win32, Direct2D)

Medido en un equipo de escritorio con Windows 11 (Intel Core i7-13700KF, 32 GB, NVIDIA GeForce RTX 3060 Ti) con una pantalla 4K de 144 Hz al 150 %, compilaciones release, la galería en una ventana de 1200 × 800 (1800 × 1200 píxeles), con cada lectura tomada automáticamente por examples/gallery/tools/perf.py (nsh test --target windows --fps, una línea por segundo; la CPU es la del proceso completo, en porcentaje de un núcleo). Las fases son las del hilo principal por fotograma: paint (Direct2D dibujando la ventana) y, dentro de ella, canvas (grabación y reproducción de dibujos).

#Demos animadas

Stocks confirma cambios entre 16 y 17 veces por segundo, cada uno en hasta 2.1 ms de JS y 1.7 ms del núcleo en el hilo del motor (p95).

#Todas las páginas

Todas las páginas de la galería, al abrirse y mientras la prueba se desplaza por ellas, en la misma ventana de 1200 × 800. Como en Linux y macOS, FPS es la tasa mientras algo se mueve (un fotograma por cada intervalo mediano entre fotogramas dibujados); a los 144 de la pantalla, cada fotograma de una animación o de un desplazamiento llega un refresco después del anterior. Por encima de un refresco es la proporción de fotogramas que tardaron más que un refresco (6.9 ms). Una página en reposo no dibuja ningún fotograma y usa entre 0 y 2% de CPU. Los GIF y WebP de Images se reproducen a sus propias tasas de fotogramas (unos 40 FPS aquí). Physics, Overlays, Menus y Storage se miden en una ventana de 900 × 500, donde tienen espacio para desplazarse.

#Memoria

En reposo, 3 s después del inicio (runners release, una ventana de 1200 × 800). El conjunto de trabajo privado es la memoria que usa el proceso por sí solo (la columna Memoria del Administrador de tareas); los bytes privados son lo que tiene confirmado; el conjunto de trabajo añade las páginas de las bibliotecas del sistema que comparte con otros procesos (Direct3D, Direct2D, DirectWrite, el controlador de la GPU):

A lo largo del recorrido por la galería, el conjunto de trabajo es de ~108–115 MB en Stocks, ~230 MB desde la página Canvas, ~320–340 MB desde la página Text View y ~390–405 MB una vez que Web and video ha abierto WebView2 (cuyas páginas se ejecutan en los procesos propios de WebView2), incluyendo lo que se guarda en caché a propósito (imágenes decodificadas, limitadas a 128 MB; los documentos de la página Text View).

#Tamaño de la app

Las apps hello world que crea nsh init con cada plantilla, tal como las compila nsh package --target windows para x86_64 (los runners de Rust con optimización en tiempo de enlazado y sin símbolos, como en Linux). El ejecutable es el <Name>.exe de la app; el zip es el .zip escrito junto a su directorio:

Qué hace posibles estas cifras:

• Fotogramas solo para los cambios, dibujados solo donde cambiaron: el ticker sincronizado con el compositor se ejecuta mientras corre una animación nativa, una transición o un callback de fotograma. Un fotograma dibuja las áreas de las vistas que cambiaron (donde estaban y donde están), sobre los píxeles que conserva la ventana, y presenta solo esas al compositor (Stocks: ~34 vistas por fotograma).
• Los canvas graban su parte animada: un dibujo se graba como listas de comandos de Direct2D, vectoriales y nítidas a cualquier escala. Cuando cambia un valor animado, solo se vuelven a grabar las operaciones desde la primera que lee un valor animado en adelante; lo que viene antes se conserva (Stocks: ~26 ms de grabación por segundo para 22 sparklines que pulsan y el gráfico).
• Solo se dibuja lo que se ve: los hijos de una vista de desplazamiento o de una vista con recorte que quedan fuera de la vista se omiten en el fotograma, y las vistas sin contenido propio no dibujan más que su fondo y su borde.

#iOS (UIKit)

Medido en el simulador de iOS (un iPhone 18 Pro Max, en el MacBook Pro anterior), compilaciones release, con el mismo recorrido (perf.py --target ios: nsh test --target ios --fps, los toques de un dedo tal como los recibe UIKit). El simulador presenta a 60 Hz; en un iPhone con pantalla ProMotion, los display links de NSH se ejecutan a los 120 Hz de la pantalla (las apps que compila nsh package y el host de desarrollo lo solicitan con CADisableMinimumFrameDurationOnPhone). Las fases son tick (animaciones nativas), drain (aplicación de los lotes del motor) y scroll (lo que sigue a una vista de desplazamiento: listas, celdas fijas, valores enlazados).

FPS es la tasa mientras algo se mueve, como arriba: a los 60 del simulador, cada fotograma llega un refresco después del anterior. Toda página en la que nada se mueve no dibuja ningún fotograma y usa entre 1 y 2% de CPU en reposo. El proceso ocupa 40 MB en la página de inicio de la galería y ~180 MB después de todo el recorrido (imágenes guardadas en caché a propósito, los documentos de la página Text View).

En un iPhone 17 Pro (ProMotion, 120 Hz), con el host de desarrollo y una demo en pantalla, las páginas animadas dibujan en cada refresco:

Stocks confirma cambios 20 veces por segundo (un tick cada 50 ms), cada uno en 1.5 ms de JS y 1.4 ms del núcleo en el hilo del motor (p95 de 2.2 y 2.0 ms), que está ocupado entre el 4 y el 6% del tiempo.

#Medir una app

Para medir una app de la misma manera, ejecuta sus pruebas o pasos con --fps y -v en --target linux, macos, windows o 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