Relatório de desempenho

O custo dos apps NSH, medido. Como o NSH os mantém rápidos e como medir o seu próprio app está em Desempenho.

#Linhas de base

A partir das linhas de base do próprio NSH (Apple silicon, salvo indicação em contrário):

Cenário	Números
App contador, headless (debug)	Primeiro quadro ~0,5–0,65 ms (58 ops / 49 itens de montagem); um toque ~0,15 ms
App contador, Mac Catalyst (release)	Primeiro quadro ~1,05–1,15 ms (cerca de 0,7 ms disso para dispor 10 textos com CoreText pela primeira vez); um toque ~0,12 ms
Lista de fotos da galeria, headless (debug)	Primeiro quadro 653 ops / 224 nós, ~2,7 ms
Rolagem da lista de fotos, Catalyst (release)	Refazer o bind de uma linha durante uma rolagem lenta ~0,4 ms; uma tela inteira de ~32 linhas em um fling rápido 0,9–1,6 ms
Rolagem da lista de fotos, emulador Android (arm64, release)	Refazer o bind de uma linha ~0,3–0,4 ms (JS ~60 µs)
Inicialização do engine (release)	~75–155 µs; as APIs globais (fetch, URL, …) não custam nada até o primeiro uso, depois ~90 µs
Hot reload	~120 ms entre salvar um arquivo e a nova versão estar em execução; aplicar a atualização leva 0,2–0,5 ms

#Linux (GTK 4)

Medido em um desktop Linux (x86_64, 24 threads, GPU NVIDIA), builds de release, a galeria em uma janela de 1896 × 1030 em um display de 120 Hz, com cada leitura feita automaticamente por examples/gallery/tools/perf.py (nsh test --target linux --fps, uma linha por segundo; a CPU é a do processo inteiro, em porcentagem de um núcleo). Frame p95 é o tempo da thread principal por quadro desenhado no percentil 95: abaixo de 8,3 ms, um quadro cabe em um refresh de 120 Hz.

#Demos animadas

#Todas as páginas

Todas as páginas da galeria, ao abrir e enquanto o teste as rola, em uma janela de 1200 × 800 em um display de 144 Hz (a mesma máquina). O NSH só desenha um quadro quando algo na tela muda, então FPS aqui é a taxa enquanto algo se move: um quadro por intervalo mediano entre quadros desenhados (perf.py, moving); nos 144 do display, cada quadro de uma animação ou de uma rolagem chega um refresh depois do anterior. Acima de um refresh é a parcela de quadros que levaram mais que um refresh (6,9 ms). GIF e WebP em Images tocam em suas próprias taxas de quadros (cerca de 50 FPS aqui), assim como o vídeo. Physics, Overlays e Menus são curtas: em 1200 × 800 uma rolagem chega ao fim em poucos quadros, então elas são medidas em uma janela de 900 × 500, onde têm espaço para rolar.

#Memória

Em repouso, 3 s após a inicialização (runners de release, janela de 480 × 640). Private é a memória que pertence apenas ao processo (USS); resident soma as páginas das bibliotecas compartilhadas (GTK, o driver da GPU), que todo app GTK na máquina compartilha:

Revisitar uma página não acrescenta memória; a primeira visita a uma página faz o processo crescer pelo que ele mantém em cache de propósito (imagens decodificadas, limitadas a 128 MB) e pelas bibliotecas que carrega no primeiro uso (WebKitGTK para web views).

#Tamanho do app

Um app hello world criado por nsh init com cada template, e dois apps usados por pessoas, como nsh package --target linux os compila para x86_64. O runner é o único executável do app; o pacote é o .tar.gz no qual ele é distribuído. Os hello worlds são compilados com link-time optimization e stripped (CARGO_PROFILE_RELEASE_LTO=fat, CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1, CARGO_PROFILE_RELEASE_STRIP=true):

Os runners TSX contêm o runtime QuickJS, os módulos nativos e o renderizador; o código do app em si é o seu bundle, ao lado do runner, com menos de 1 KB em um hello world.

O que explica esses números:

• O renderizador: com o driver da NVIDIA, o NSH desenha com o renderizador GL do GSK, cujos quadros custam uma fração dos do renderizador Vulkan nesse caso (a demo Animations: ~1 ms de desenho por quadro em vez de ~9,5 ms). GSK_RENDERER ainda escolhe.
• Rasters do canvas: cada canvas é rasterizado uma vez em tiles de 256 px mantidos na GPU. Um valor animado redesenha apenas a área que as operações que o leem cobrem, sobre os pixels mantidos da parte estática do desenho; um canvas fora de vista espera até rolar para dentro da visão.
• Paths postos de lado uma vez: fillRect e fillText depois de um path longo o deixam no lugar até que seja usado de novo (uma linha de 400 pontos e depois 240 barras: 0,63 ms).

#macOS (AppKit)

Medido em um MacBook Pro (Apple M3, 24 GB) em seu display ProMotion integrado de 120 Hz, builds de release, a galeria em uma janela de 1200 × 800, com cada leitura feita automaticamente por examples/gallery/tools/perf.py (nsh test --target macos --fps, uma linha por segundo; a CPU é a do processo inteiro, em porcentagem de um núcleo, e a GPU, sua parcela da GPU). As fases são as da thread principal por quadro: tick (as animações nativas do display link) e canvas (a reprodução dos desenhos).

#Demos animadas

Em Stocks, o tempo da thread principal por quadro é de ~1,6 ms de ticks, dos quais ~0,45 ms reproduzem as partes animadas dos canvases; o Core Animation desenha o restante de cada canvas em suas próprias threads.

#Todas as páginas

Todas as páginas da galeria, ao abrir e enquanto o teste as rola, na mesma janela de 1200 × 800. Como no Linux, FPS é a taxa enquanto algo se move (um quadro por intervalo mediano entre quadros desenhados); nos 120 do display, cada quadro de uma animação ou de uma rolagem chega um refresh depois do anterior. Acima de um refresh é a parcela de quadros que levaram mais que um refresh (8,3 ms). Uma página em repouso não desenha quadros e usa de 2 a 5% de CPU. GIF e WebP em Images tocam no Core Animation e o vídeo no AVFoundation, em suas próprias taxas de quadros.

#Memória

Em repouso, 3 s após a inicialização (runners de release). Footprint é a memória que o macOS atribui ao processo (o que o Activity Monitor mostra); resident soma as páginas das bibliotecas compartilhadas do sistema:

Ao longo do tour da galeria, o processo mantém de 84 a 230 MB até a página Canvas e ~350–360 MB a partir da página Text View, com o que ele mantém em cache de propósito (imagens decodificadas, limitadas a 128 MB; os documentos da página Text View) e os frameworks que carrega no primeiro uso (WebKit para web views); os rasters da página Canvas, até ~310 MB com os três canvases na tela, são liberados quando a página fecha.

#Tamanho do app

Os apps hello world criados por nsh init com cada template, como nsh package --target macos os compila para Apple silicon (arm64), com link-time optimization e stripped como no Linux, e os dois apps acima como são distribuídos para Apple silicon. O executável é o runner dentro do .app; o zip é o .app compactado (ditto -c -k):

O que explica esses números:

• Quadros só para mudanças: o display link dispara enquanto uma animação nativa roda e para junto com ela; uma animação para com a sua página (a exclusão da sua view encerra seus keyframes, um loop para no cleanup do seu componente).
• Canvases desenhados onde custam menos: um canvas que pinta com frequência (uma animação, dados ao vivo) desenha nas threads do Core Animation (drawsAsynchronously), o que mantém a thread principal livre; um canvas redesenhado de vez em quando desenha imediatamente, sem a memória gráfica que o desenho assíncrono retém. Um valor animado redesenha apenas a área coberta pelas operações que o leem.
• Partes estáticas do canvas mantidas: quando um desenho permanece inalterado, uma parte longa antes da sua primeira operação animada é mantida como uma layer; a cada quadro, essa layer é desenhada e apenas o restante animado é reexecutado, imediatamente na thread principal (o medidor, o relógio e a matriz de pontos da página Canvas: nenhum trabalho de GPU e metade da memória).
• Conteúdo desenhado quando muda: textos e canvases desenham em layers próprias, de novo quando o conteúdo ou o tamanho muda, não quando se movem ou rolam.

#Windows (Win32, Direct2D)

Medido em um desktop com Windows 11 (Intel Core i7-13700KF, 32 GB, NVIDIA GeForce RTX 3060 Ti) com um display 4K de 144 Hz a 150%, builds de release, a galeria em uma janela de 1200 × 800 (1800 × 1200 pixels), cada leitura feita automaticamente por examples/gallery/tools/perf.py (nsh test --target windows --fps, uma linha por segundo; a CPU é a do processo inteiro, em porcentagem de um núcleo). As fases são as da thread principal por quadro: paint (o Direct2D desenhando a janela) e, dentro dela, canvas (gravação e reexecução de desenhos).

#Demos animadas

Stocks faz de 16 a 17 commits por segundo, cada um em até 2,1 ms de JS e 1,7 ms do core na thread do engine (p95).

#Todas as páginas

Todas as páginas da galeria, ao abrirem e enquanto o teste as rola, na mesma janela de 1200 × 800. Como no Linux e no macOS, FPS é a taxa enquanto algo se move (um quadro por intervalo mediano entre quadros desenhados); a 144 do display, cada quadro de uma animação ou de uma rolagem vem um refresh depois do anterior. Mais de um refresh é a proporção de quadros que levaram mais que um refresh (6,9 ms). Uma página em repouso não desenha quadros e usa de 0 a 2% de CPU. Os GIF e WebP de Images rodam em suas próprias taxas de quadros (cerca de 40 FPS aqui). Physics, Overlays, Menus e Storage são medidas em uma janela de 900 × 500, onde há espaço para rolar.

#Memória

Em repouso, 3 s após a inicialização (runners de release, janela de 1200 × 800). Private working set é a memória que o processo usa sozinho (coluna Memory do Task Manager); private bytes é o que ele tem alocado (committed); working set soma as páginas das bibliotecas do sistema que ele compartilha com outros processos (Direct3D, Direct2D, DirectWrite, o driver da GPU):

Ao longo do tour da galeria, o working set fica em ~108–115 MB em Stocks, ~230 MB a partir da página Canvas, ~320–340 MB a partir da página Text View e ~390–405 MB depois que Web and video abre o WebView2 (cujas páginas rodam nos processos próprios do WebView2), com o que ele guarda em cache de propósito (imagens decodificadas, limitadas a 128 MB; os documentos da página Text View).

#Tamanho do app

Os apps hello world criados por nsh init com cada template, como nsh package --target windows os compila para x86_64 (os runners Rust com link-time optimization e stripped, como no Linux). O executável é o <Name>.exe do app; o zip é o .zip gravado ao lado do seu diretório:

O que explica esses números:

• Quadros só para mudanças, desenhados só onde mudaram: o ticker sincronizado com o compositor roda enquanto uma animação nativa, uma transição ou um frame callback está em execução. Um quadro desenha as áreas das views que mudaram (onde estavam e onde estão), sobre os pixels que a janela mantém, e apresenta ao compositor apenas essas áreas (Stocks: ~34 views por quadro).
• Canvases gravam sua parte animada: um desenho é gravado como command lists do Direct2D, vetorial e nítido em qualquer escala. Quando um valor animado muda, apenas as operações a partir da primeira que lê um valor animado são gravadas de novo; o que vem antes é mantido (Stocks: ~26 ms de gravação por segundo para 22 sparklines pulsantes e o gráfico).
• Só o que aparece é desenhado: os filhos de uma scroll view ou de uma view com clipping que estão fora de vista ficam de fora do quadro, e views sem conteúdo próprio desenham apenas o fundo e a borda.

#iOS (UIKit)

Medido no simulador do iOS (um iPhone 18 Pro Max, no MacBook Pro acima), builds de release, com o mesmo tour (perf.py --target ios: nsh test --target ios --fps, os toques de um dedo como o UIKit os recebe). O simulador apresenta a 60 Hz; em um iPhone com tela ProMotion, os display links do NSH rodam a 120 Hz da tela (os apps que nsh package compila e o host de desenvolvimento pedem isso com CADisableMinimumFrameDurationOnPhone). As fases são tick (animações nativas), drain (aplicação dos batches do engine) e scroll (o que acompanha uma scroll view: listas, células sticky, valores vinculados).

FPS é a taxa enquanto algo se move, como acima: a 60 do simulador, cada quadro vem um refresh depois do anterior. Toda página sem nada se movendo não desenha quadros e usa de 1 a 2% de CPU em repouso. O processo ocupa 40 MB na página inicial da galeria e ~180 MB depois do tour completo (imagens em cache de propósito, os documentos da página Text View).

Em um iPhone 17 Pro (ProMotion, 120 Hz), com o host de desenvolvimento e uma demo na tela, as páginas animadas desenham a cada refresh:

Stocks faz 20 commits por segundo (um tick a cada 50 ms), cada um em 1,5 ms de JS e 1,4 ms do core na thread do engine (p95 de 2,2 e 2,0 ms), que fica ocupada de 4 a 6% do tempo.

#Medindo um app

Para medir um app da mesma forma, execute seus testes ou steps com --fps e -v em --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