Numeri che puoi riprodurre.

Ambiente

Ogni dato di questa pagina proviene da un solo computer: il portatile su cui viene sviluppata l'app, una normale configurazione con grafica integrata. Le versioni per macOS e Windows sono in sviluppo; le relative righe compariranno qui quando esisteranno.

Documento di prova: tools/perf/fixtures/doc100k.md (100 KB, 874 righe) · 3 esecuzioni, mediana · puntatore fermo fuori dalla finestra · bus di sessione reale.

Frame inattivi

Affermazione: quando non succede nulla, mote non disegna nulla. Con il documento aperto nella vista Live, l'editor senza stato attivo, così il cursore non lampeggia, e nessun input per 10 secondi (t = 5–15 s dopo l'avvio), contiamo gli snapshot dell'editor: ogni volta che GTK gli chiede di disegnare.

Con il lampeggiamento del cursore attivo, come avviene per impostazione predefinita quando la finestra è in primo piano, si registra un ridisegno dell'editor per ogni lampeggio — cambia soltanto il cursore — e si interrompe non appena la finestra perde lo stato attivo. Quel lampeggio è l'unico timer che l'app può mantenere; quando è inattiva non esistono altre attività ripetute.

Latenza di input

Affermazione: 9.7 ms dal tasto al pixel, al 95° percentile. Tasto → elaborazione: p95 0.29 ms. Tasto → pixel (vsync incluso): p95 9.7 ms. Misurato all'interno del processo da tools/perf/typing.sh, con un documento da 100 KB nella vista Live.

Per «elaborato» si intende che l'evento di input ha aggiornato il documento e invalidato i layout interessati; «pixel» indica la fine dello snapshot successivo, che attende il clock dei frame e quindi ha come limite inferiore il vsync (16.7 ms a 60 Hz). Su oltre 300 battute, le due distribuzioni sono state p50 0.01 / p95 0.29 / max 0.48 ms e p50 2.6 / p95 9.7 / max 12.7 ms, misurate il 2026-09-02 sulla versione M3, con un commit precedente a quello della prova di conformità riportata sotto; l'esecuzione di digitazione non è ancora nella directory dei risultati, quindi ripetila prima di considerarla attendibile. Il tempo di risposta dello schermo non è incluso; non lo abbiamo misurato.

Avvio a freddo

Affermazione: 211 ms dall'avvio alla finestra, con un file da 100 KB aperto. «A freddo» significa un processo nuovo con il file aperto all'avvio; nulla viene preparato in anticipo e la cache delle pagine resta com'è. Il cronometro parte da exec e si ferma quando la finestra viene mappata; per il primo disegno si usa lo stesso cronometro, fermato al primo snapshot del documento da parte dell'editor.

Metodo: tools/perf/gate.sh, a freddo = processo nuovo, file da 100 KB aperto all'avvio. Il PSS viene letto da /proc dopo quindici secondi, quando il documento è stato impaginato e l'app è tornata inattiva.

Stesso computer, stesso documento

Typora, Obsidian e MarkText sono stati aperti uno alla volta sullo stesso documento da 100 KB nella rispettiva vista di modifica in linea — WYSIWYG di Typora, Live Preview di Obsidian e MarkText — sul computer indicato sopra e mediante lo stesso script. La memoria è il PSS dell'intero albero dei processi dodici secondi dopo l'avvio; la CPU inattiva è il consumo dell'albero tra il quinto e il decimo secondo, con la finestra in primo piano e nessun input; la CPU in digitazione è il consumo dell'albero mentre vengono inseriti circa 150 caratteri, uno ogni 30 ms. Sette esecuzioni per editor, media, dopo aver scartato una prima esecuzione di riscaldamento.

La CPU inattiva di Typora è bassa quanto la nostra — lo diciamo chiaramente. Chromium riduce l'attività quando è davvero inattivo, quindi la colonna relativa all'inattività distingue mote da Obsidian e MarkText, non da Typora. La differenza tra i motori emerge nella memoria e nel costo della digitazione: un processo contro sei-otto e un decimo della CPU per battuta. I 78 MB indicati qui superano i 69 MB riportati sopra perché rappresentano l'intero albero dei processi in una sessione diversa; il consumo di base di GTK e Mesa varia di una dozzina di megabyte tra le sessioni.

MarkText è stato eseguito con --no-sandbox, perché la sua sandbox non si avvia su questo kernel; Obsidian è stato eseguito in un vault nuovo con soli tre plugin principali. Dati grezzi: experiments/2026-09-03-apps-idle-startup/raw.csv.

Riproduci le misurazioni

Il sistema di prova, il corpus, i CSV grezzi e i risultati JSON saranno pubblicati con la beta in un repository pubblico di benchmark su GitHub. tools/perf/gate.sh <binary> :1 3 esegue la prova di conformità; tools/perf/bench-apps.sh il confronto. Se i tuoi numeri differiscono dai nostri di oltre il 15 %, comunicacelo; pubblicheremo la discrepanza.

Ultima esecuzione: prova di conformità del 2026-09-03 sul commit 04cf7dc, confronto con b17c3bf; latenza di digitazione misurata il 2026-09-02 sulla versione M3. Da ripetere a ogni rilascio.