63 MB: quanto costa un editor di codice per Mac quando non è un browser

Un editor è l'applicazione che non si chiude mai. Sta lì tutto il giorno dietro al browser, alla posta e alla videochiamata, a tenere le tue frasi incompiute. Qualunque cosa costi, la costa per tutto il tempo, e la costa sulla stessa macchina su cui volevi anche compilare qualcosa.

Così abbiamo misurato MeatPad invece di tirare a indovinare, su un normale Mac di lavoro con tutto il resto ancora acceso.

I numeri

Tre scenari, una macchina, un pomeriggio:

MeatPad 0.10.2 · macOS 26.5.2 · Apple silicon

finestra note aperta, 19 h                63 MB    picco 83 MB
progetto di 2.721 file, 6 schede         108 MB    picco 131 MB
un solo file di testo da 6,3 MB         1500 MB    vedi la sezione onesta

VS Code 1.130.0, stessa cartella, stessi 6 file
                                         710 MB    su 8 processi

La riga centrale è quella che conta, perché è la configurazione di lavoro: un repository vero con albero dei file, sei schede aperte, evidenziazione della sintassi, ricerca su tutto il progetto e completamento attivi. Si assesta a 108 MB e lì resta. Il picco di 131 MB è la prima passata sul progetto, che costruisce l'indice degli identificatori per il completamento, e quella memoria viene subito restituita.

La riga di VS Code serve come contrasto, non come verdetto: una cartella utente nuova, nessuna estensione installata, la stessa cartella e gli stessi sei file, misurati un minuto dopo l'avvio. Fa molto più di MeatPad, e buona parte di quella differenza è l'ecosistema di estensioni che in molti giustamente vogliono. Il confronto riguarda il pavimento, non chi vince.

Verifica da solo, e diffida del numero sbagliato

Due strumenti sul tuo Mac si contraddicono, e uno solo ha ragione. Mentre MeatPad dichiarava 63 MB, ps riportava 147 MB per lo stesso processo nello stesso istante:

$ ps -o rss= -p $(pgrep -x MeatPad)
  150304

$ footprint -p $(pgrep -x MeatPad)
    phys_footprint: 63 MB
    phys_footprint_peak: 83 MB

La resident set size conta ogni pagina mappata nel processo, comprese le pagine condivise, in sola lettura e copy-on-write di AppKit, SwiftUI, CoreText e del resto del sistema. Quelle pagine sono residenti una volta sola per tutto il Mac e non vengono addebitate a nessuno. L'impronta fisica conta solo ciò di cui questo processo è davvero responsabile, ed è anche il numero che Monitoraggio Attività mostra nella colonna Memoria. Quando qualcuno cita un dato di memoria per un'app Mac nativa, chiedi quale dei due ha misurato.

Motivo uno: dentro il processo non c'è nessun browser

MeatPad è un'applicazione nativa: Swift, AppKit e SwiftUI, 92 file sorgente e circa quindicimilacinquecento righe, pacchetto framework compreso. Niente Chromium, nessun runtime JavaScript, nessun processo Node, nessun host di plugin, nessuna copia privata di un toolkit di interfaccia dentro il bundle.

È tutto qui il trucco dei primi cento megabyte. Un editor costruito su uno stack web deve portarsi un browser al lavoro, e un browser è un sistema operativo con idee proprie: motore di layout proprio, garbage collector proprio, un processo per finestra, una copia propria di tutto. Prima di disegnare un solo carattere del tuo codice ha già pagato tutto quanto. Un'app nativa prende in prestito dalla macchina il motore di layout, il motore di testo e il toolkit, dove erano già caricati per il Finder.

Motivo due: l'editor impagina le righe che riesci a vedere

È nell'impaginazione del testo che gli editor sbagliano in silenzio. Misurare ogni riga di un documento lungo, con font e larghezza esatti, perché una barra di scorrimento abbia l'altezza giusta, è moltissimo lavoro da fare prima di mostrare qualsiasi cosa.

MeatPad disegna tramite STTextView su TextKit 2, lo stack di testo attuale di Apple, che lavora sull'area visibile. Impagina i frammenti a schermo e poco oltre, e se ne dimentica appena escono. Aprire un file significa leggerlo e disegnare una schermata. Il costo del resto del documento è rinviato a quando ci scorri sopra, e liberato quando te ne allontani.

Motivo tre: le tue note sono file su disco, non un database in memoria

Ogni nota è un normale file di testo con un piccolo JSON accanto. L'app non carica un'area di lavoro in memoria per abitarci. Solo i documenti che hai davvero aperti trattengono il loro testo, e chiudere una finestra lo restituisce.

Lo stesso istinto attraversa le funzioni di progetto:

• L'albero dei file legge prima un solo livello, così la finestra compare subito, e sostituisce l'albero completo quando è pronto.
• La ricerca su tutto il progetto legge i file dal disco in parallelo al momento della ricerca. Tra una ricerca e l'altra non resta in memoria nessun indice persistente, perché il disco è veloce e il tuo progetto non è così grande.
• L'indice di completamento memorizza i conteggi degli identificatori per file invece del contenuto dei file, e salta tutto ciò che supera i quattro megabyte.
• L'evidenziazione della sintassi è tree-sitter: parser compatti scritti in C, un albero per documento aperto, riaggiornato in modo incrementale mentre scrivi invece che ricostruito.

Motivo quattro: l'intelligenza costosa vive in un altro processo

L'intelligenza di un editor costa davvero. Un language server tiene un modello semantico dell'intero progetto, e per una grande base di codice Rust o Swift quel modello supera di gran lunga tutto ciò che un editor fa con il testo.

MeatPad non ospita quel lavoro. Parla il Language Server Protocol con server già installati sulla tua macchina, SourceKit-LSP, rust-analyzer, Pyright, ciascuno nel proprio processo, avviato quando si apre un progetto e chiuso quando lo si chiude. Qualunque cosa costi il modello semantico viene addebitata al server, è visibile con il suo nome in Monitoraggio Attività e viene restituita nel momento in cui chiudi il progetto. L'editor tiene i messaggi, non il modello. Se non è installato alcun server, il completamento ripiega sugli identificatori del progetto aperto e tutto il resto continua a funzionare.

È anche per questo che i numeri qui sopra sono onesti e non comodi. Non sono bassi perché delle funzioni siano state tolte e spinte in un altro processo per nasconderle. Sono bassi perché le parti che hanno bisogno di molta memoria sono quelle a cui è permesso avere la propria.

Dove questo progetto morde

La terza riga di quella tabella non era un errore di battitura. Apri un singolo file di testo da 6,3 MB, circa centoventinovemila righe, e MeatPad supera il gigabyte e satura un core.

La causa non è il motore di testo, che si comporta esattamente come promesso. È la barra di stato. Mostra righe, parole e caratteri del documento, e calcola tutti e tre percorrendo l'intero testo ogni volta che l'interfaccia si reimpagina. Su una nota o su un file sorgente sono pochi kilobyte e nessuno se ne accorge. Su centoventinovemila righe ogni passata di impaginazione diventa una scorsa completa di sei megabyte di testo, e l'interfaccia si reimpagina moltissimo.

La correzione è piccola, i conteggi vanno calcolati una volta quando il testo cambia invece che a ogni disegno, ed è in coda. Lo scriviamo qui invece di ometterlo perché un articolo sulla memoria che elenca solo le misure buone è una pubblicità. I file di tutti i giorni, quelli su cui gli editor vengono davvero puntati, stanno nelle prime due righe. I file singoli molto grandi sono la frontiera, e tocca a noi sistemarla.

Perché tutto questo vale un pomeriggio

La maggior parte dei Mac venduti ha 16 GB di memoria, e quasi nessuno ha un gigabyte da buttare: il browser ha trenta schede, lo strumento di design è aperto, qualcosa sta compilando. La memoria che un editor trattiene è memoria che il compilatore non può usare, e quando finisce macOS inizia a comprimere e a usare lo swap, cosa che percepisci come tutto che peggiora leggermente insieme.

Un'app nativa che prende in prestito i framework di sistema, impagina solo ciò che è visibile, tiene i tuoi documenti come file e lascia che i language server girino nei propri processi finisce intorno ai 63 MB senza che nessuno abbia ottimizzato niente. Non è una storia di ingegneria eroica. È il normale risultato del non aver costruito prima un browser.