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. La versione per Windows non è ancora stata misurata qui e quella per macOS è 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, mori 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: 18.2 ms dal tasto al pixel, al 95° percentile. Misurato dall'esterno del processo da tools/perf/index/e2e_latency.sh: un tasto viene iniettato con XTest e lo schermo interrogato finché la riga del cursore non cambia. Documento da 100 KB, vista Live, 2560×1440 a 180 Hz. Su 119 battute: p50 14.1, p95 18.2, p99 19.1, max 20.4 ms.

Il numero comprende tutto ciò che sta tra il tasto e il pixel: il toolkit, il compositor e l'attesa del fotogramma successivo. Quell'attesa cade in un punto qualsiasi tra zero e un intervallo di refresh — a 180 Hz al massimo 5.6 ms, 2.8 in media — ed è per questo che si può affiancare solo a un altro editor misurato allo stesso refresh. Il tempo di risposta dello schermo non è incluso; non lo abbiamo misurato.

Avvio a freddo

Affermazione: 387 ms dall'avvio alla finestra, con un file da 100 KB aperto e niente in cache. A freddo significa processo nuovo e page cache svuotata: binario, librerie e file arrivano tutti dal disco. Con la cache calda — il caso di ogni giorno — lo stesso avvio richiede 259 ms. L'orologio parte da exec e si ferma quando la finestra compare; il primo disegno è lo stesso orologio fermato alla prima resa del documento.

Metodo: tools/perf/run-index.sh, a freddo = processo nuovo con page cache svuotata, file da 100 KB aperto all'avvio, cinque passaggi. La memoria è il PSS letto da /proc quando il documento è impaginato e l'app è a riposo, meno la stessa lettura con un documento vuoto — quanto ci costa il documento: 9.4 MB su 70 MB. Il resto è lo zoccolo di toolkit e GPU che ogni applicazione GTK4 paga su questa macchina; si muove con il driver, ed è per questo che pubblichiamo la nostra parte. Il binario pesa 6.1 MB. Il primo disegno si legge dal contatore di frame dell'editor, che ha solo la nostra build dev — gli altri tre mostrano un trattino invece di una stima.

Stesso computer, stesso documento

Typora, Obsidian e MarkText, ciascuno aperto sullo stesso documento da 100 KB nella propria vista di modifica in linea (il WYSIWYG di Typora, la Live Preview di Obsidian, MarkText), sulla macchina qui sopra e nella stessa esecuzione dei nostri numeri. La memoria è il PSS dell'intero albero di processi quando il documento è impaginato e l'app è a riposo; la CPU a riposo è quella dell'albero su trenta secondi con la finestra a fuoco e senza input; la CPU di battitura è quella dell'albero mentre si digitano circa 700 caratteri a ritmo umano, uno ogni 150 ms.

I motori si dividono prima di tutto a riposo: con la finestra aperta e nulla da fare, mori non usa CPU misurabile e si sveglia zero volte al secondo, mentre i tre editor Electron stanno all'1.1–1.6 % con 29–75 risvegli. Poi la battitura: una frazione di core contro un terzo o due terzi. Infine la memoria: un processo contro sei o nove, 70 MB contro 346–457.

MarkText è stato eseguito con --no-sandbox (la sua sandbox non parte su questo kernel); Obsidian è stato eseguito in una cartella dati separata. Dati grezzi: tools/perf/results/2026-09-09-linux-myasus-180hz.json.

Riproduci le misurazioni

L'harness e il file dei risultati stanno nel repository; un repository pubblico con corpus e dati grezzi è in preparazione e non ha ancora una data. tools/perf/run-index.sh esegue tutti gli indici; tools/perf/check.sh valida il risultato rispetto ai budget. Se i tuoi numeri si discostano dai nostri di oltre il 15 %, faccelo sapere; pubblichiamo lo scarto.

Ultima esecuzione: 2026-09-09, una sola passata di tools/perf/run-index.sh sul commit 183cc22 — ogni numero di questa pagina, il nostro e quello degli altri editor, viene da quella passata. Si ripete a ogni release.