Perché la digitazione non rallenta anche quando il documento diventa lungo
Con una nota breve, qualsiasi editor è veloce. La differenza emerge quando il documento si allunga, e dipende dal fatto che il costo di una singola pressione segua le dimensioni della modifica oppure quelle del documento.
Una nota breve è veloce con qualsiasi editor. La differenza si manifesta quando il documento si allunga.
Se a ogni pressione di un tasto si rilegge l’intero documento e si riorganizza lo schermo, anche l’immissione rallenta man mano che il documento si allunga. È per questo che un editor che andava bene con una nota di dieci righe diventa frustrante con un documento di progettazione di duemila righe.
mote non ha considerato questo problema come una questione di prestazioni da risolvere in seguito. Fin dall’inizio lo ha stabilito come principio di progettazione da rispettare.
Durante la modifica, rilegge e dispone nuovamente solo l’intervallo modificato. L’intero documento viene riletto soltanto quando si apre il file.
Rilegge solo ciò che è cambiato
Nel Markdown, una riga precedente può cambiare il significato di quelle successive. Se si apre un blocco di codice nella parte alta del documento, tutto il contenuto sottostante può diventare codice, e la stessa frase viene interpretata diversamente all’interno di un elenco o di una citazione.
Perciò mote memorizza i «punti sicuri» in cui l’influenza di ciò che precede è sicuramente terminata. Quando avviene una modifica, inizia a leggere dal punto sicuro più vicino e si ferma non appena il contenuto torna a stabilizzarsi.
I blocchi successivi non vengono riletti. Se il numero di righe è aumentato o diminuito, ne viene spostata soltanto la posizione. In questo modo, il costo segue l’intervallo effettivamente modificato anziché l’intero documento.
Il parser segue l’algoritmo riga per riga di CommonMark e supera tutti i 652 test della specifica. Tuttavia, nell’elaborazione incrementale è facile ottenere silenziosamente risultati errati. Per questo motivo, dopo aver applicato 3.600 modifiche casuali a documenti casuali, ogni volta il risultato viene confrontato con quello ottenuto rileggendo l’intero documento.
Questo controllo ha individuato anche un bug reale. Si verificava quando il punto sicuro coincideva esattamente con la riga modificata.
I principi delle prestazioni vengono tutelati con i controlli
L’obiettivo è un p95 di 4 ms dalla pressione di un tasto fino al completamento dell’elaborazione del core. Se si supera questo tempo, il problema viene trattato come un bug, non come un’attività di miglioramento.
Le regole non sono state semplicemente annotate nella documentazione. Un controllo automatico verifica che la nuova analisi sintattica dell’intero documento venga utilizzata soltanto all’apertura di un file. Impedisce anche timer o operazioni sui frame che si ripetono durante lo stato di inattività.
Nemmeno le prestazioni vengono giudicate a occhio. L’harness inserisce realmente i tasti sullo schermo e misura la distribuzione dei tempi di elaborazione. Si osserva il p95 anziché la media o la mediana. Questo perché a frustrare l’utente non è tanto la velocità abituale, quanto i lunghi ritardi che compaiono occasionalmente.
Per le misurazioni viene sempre utilizzato lo stesso documento fisso.
doc100k.md usato dall’harness, aperto in modalità live. La barra di stato mostra 96.513 caratteri e un tempo di lettura di 103 minuti.Anche lo schermo cambia solo quanto necessario
Non era sufficiente rendere incrementale soltanto il parser.
L’evidenziazione sintattica dei blocchi di codice rielaborava tutti i blocchi a ogni modifica. Era l’ultima operazione che rallentava con l’aumentare della lunghezza del documento, indipendentemente dalle dimensioni della modifica.
Ora l’evidenziazione sintattica dei blocchi non modificati viene riutilizzata così com’è. I blocchi successivi alla modifica vengono soltanto spostati in base alla variazione del numero di righe.
I blocchi fuori dallo schermo non vengono sottoposti a layout. Questo perché, per mantenere la velocità anche nei documenti lunghi, bisogna ridurre sia l’intervallo da rileggere sia quello da ridisegnare.
Ci sono anche delle eccezioni
In alcuni casi è necessario rielaborare l’intero documento.
Succede quando si apre un file o cambia il formato delle interruzioni di riga. Se si modifica la definizione di un riferimento a un link, può cambiare qualsiasi link presente nel documento, quindi anche l’intervallo di aggiornamento dello schermo viene esteso all’intero documento.
Anche se il core è veloce, lo schermo deve attendere il frame successivo. Su uno schermo a 60 Hz, l’intervallo tra i frame costituisce di per sé un limite. Per questo motivo, il tempo di elaborazione del core e quello necessario perché il risultato appaia effettivamente sullo schermo vengono misurati separatamente, senza collocare i due valori sullo stesso asse. È per questo che le due righe della copertina sono diverse.
Un editor veloce non è un editor che fa tutto rapidamente.
È un editor che non fa ciò che non è necessario fare.