63 MB: quanto custa um editor de código no Mac quando ele não é um navegador

Um editor é o aplicativo que a gente nunca fecha. Ele fica o dia inteiro atrás do navegador, do e-mail e da videochamada, guardando suas frases inacabadas. Custe o que custar, ele custa o tempo todo, e custa na mesma máquina em que você também queria compilar alguma coisa.

Então medimos o MeatPad em vez de chutar, num Mac de trabalho comum com todo o resto ainda rodando.

Os números

Três cenários, uma máquina, uma tarde:

MeatPad 0.10.2 · macOS 26.5.2 · Apple silicon

janela de notas aberta, 19 h              63 MB    pico 83 MB
projeto de 2.721 arquivos, 6 abas        108 MB    pico 131 MB
um único arquivo de texto de 6,3 MB     1500 MB    veja a seção honesta

VS Code 1.130.0, mesma pasta, mesmos 6 arquivos
                                         710 MB    em 8 processos

A linha do meio é a que importa, porque é a configuração de trabalho: um repositório de verdade com árvore de arquivos, seis abas abertas, realce de sintaxe, busca em todo o projeto e autocompletar ativos. Ela se estabiliza em 108 MB e fica ali. O pico de 131 MB é a primeira passagem pelo projeto, que constrói o índice de identificadores para o autocompletar, e essa memória é devolvida logo em seguida.

A linha do VS Code serve de contraste, não de veredito: um diretório de usuário novo, nenhuma extensão instalada, a mesma pasta e os mesmos seis arquivos, medido um minuto depois de abrir. Ele faz muito mais do que o MeatPad, e boa parte dessa diferença é o ecossistema de extensões que muita gente quer, com razão. A comparação é sobre o piso, não sobre quem ganha.

Confira você mesmo, e desconfie do número errado

Duas ferramentas do seu Mac se contradizem aqui, e só uma está certa. Enquanto o MeatPad informava 63 MB, o ps dizia 147 MB para o mesmo processo no mesmo instante:

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

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

O resident set size conta cada página mapeada no processo, inclusive as páginas compartilhadas, somente leitura e copy-on-write do AppKit, do SwiftUI, do CoreText e do resto do sistema. Essas páginas ficam residentes uma única vez para o Mac inteiro e não são cobradas de ninguém. A pegada física conta apenas aquilo pelo que esse processo é realmente responsável, que é também o número que o Monitor de Atividade mostra na coluna Memória. Quando alguém citar um número de memória de um app nativo de Mac, pergunte qual dos dois foi medido.

Motivo um: não há navegador nenhum dentro do processo

O MeatPad é um aplicativo nativo: Swift, AppKit e SwiftUI, 92 arquivos de código e cerca de quinze mil e quinhentas linhas, incluindo seu próprio pacote de framework. Não há Chromium, nem runtime JavaScript, nem processo Node, nem hospedeiro de plugins, nem cópia privada de um kit de interface dentro do pacote.

É esse o truque inteiro por trás dos primeiros cem megabytes. Um editor construído sobre uma pilha web precisa levar um navegador junto para o trabalho, e um navegador é um sistema operacional com opiniões próprias: motor de layout próprio, coletor de lixo próprio, um processo por janela, uma cópia própria de tudo. Antes de desenhar um único caractere do seu código, ele já pagou por tudo isso. Um app nativo pega emprestado da máquina o motor de layout, o motor de texto e o kit de interface, que já estavam carregados para o Finder.

Motivo dois: o editor diagrama as linhas que você consegue ver

É na diagramação do texto que os editores erram em silêncio. Medir cada linha de um documento longo, com a fonte e a largura exatas, para que a barra de rolagem tenha a altura certa, é muito trabalho antes de mostrar qualquer coisa a alguém.

O MeatPad desenha através do STTextView sobre o TextKit 2, a pilha de texto atual da Apple, que trabalha pela área visível. Ela diagrama os fragmentos que estão na tela e um pouco além, e os esquece assim que saem. Abrir um arquivo é lê-lo e desenhar uma tela. O custo do resto do documento é adiado até você rolar até lá, e liberado quando você se afasta.

Motivo três: suas notas são arquivos no disco, não um banco de dados na memória

Cada nota é um arquivo de texto comum com um pequeno JSON ao lado. O aplicativo não carrega um espaço de trabalho na memória para morar lá. Só os documentos que você realmente tem abertos seguram o texto deles, e fechar uma janela devolve isso.

O mesmo instinto atravessa os recursos de projeto:

• A árvore de arquivos lê primeiro um nível só, para a janela aparecer na hora, e troca pela árvore completa quando ela fica pronta.
• A busca em todo o projeto lê os arquivos do disco em paralelo na hora da busca. Não há índice de busca persistente ocupando memória entre uma busca e outra, porque o disco é rápido e o seu projeto não é tão grande assim.
• O índice de autocompletar guarda contagens de identificadores por arquivo em vez do conteúdo dos arquivos, e pula tudo o que passa de quatro megabytes.
• O realce de sintaxe é tree-sitter: analisadores compactos escritos em C, uma árvore por documento aberto, reanalisada de forma incremental enquanto você digita, em vez de reconstruída.

Motivo quatro: a inteligência cara mora em outro processo

A inteligência de um editor é realmente cara. Um servidor de linguagem mantém um modelo semântico do seu projeto inteiro, e para uma base de código grande em Rust ou Swift esse modelo faz parecer pequeno tudo o que um editor faz com texto.

O MeatPad não hospeda esse trabalho. Ele fala o Language Server Protocol com servidores já instalados na sua máquina, SourceKit-LSP, rust-analyzer, Pyright, cada um no seu próprio processo, iniciado quando um projeto abre e encerrado quando ele fecha. O que o modelo semântico custar é cobrado do servidor, aparece com o nome dele no Monitor de Atividade e volta no instante em que você fecha o projeto. O editor guarda as mensagens, não o modelo. Se nenhum servidor estiver instalado, o autocompletar recorre aos identificadores do projeto aberto e todo o resto continua funcionando.

É também por isso que os números acima são honestos em vez de convenientes. Eles não são baixos porque recursos foram retirados e empurrados para outro processo a fim de escondê-los. São baixos porque as partes que precisam de muita memória são justamente as que têm permissão de ter a sua.

Onde esse projeto morde

A terceira linha daquela tabela não foi erro de digitação. Abra um único arquivo de texto de 6,3 MB, cerca de cento e vinte e nove mil linhas, e o MeatPad passa de um gigabyte e trava um núcleo em 100%.

A causa não é o motor de texto, que se comporta exatamente como anunciado. É a barra de status. Ela mostra linhas, palavras e caracteres do documento, e calcula os três percorrendo o texto inteiro toda vez que a interface se rediagrama. Numa nota ou num arquivo-fonte, isso são poucos kilobytes e ninguém percebe. Em cento e vinte e nove mil linhas, cada passagem de diagramação vira uma varredura completa de seis megabytes de texto, e a interface se rediagrama muitíssimo.

A correção é pequena, as contagens precisam ser calculadas uma vez quando o texto muda, e não uma vez por desenho, e ela está na fila. Estamos escrevendo isso aqui em vez de omitir porque um artigo sobre memória que só lista as boas medições é um anúncio. Os arquivos do dia a dia, aqueles para os quais editores são de fato apontados, cabem nas duas primeiras linhas. Arquivos únicos muito grandes são a fronteira, e consertá-la é conosco.

Por que isso vale uma tarde

A maioria dos Macs vendidos tem 16 GB de memória, e quase ninguém tem um gigabyte sobrando: o navegador está com trinta abas, a ferramenta de design está aberta, alguma coisa está compilando. A memória que um editor segura é memória que o compilador não pode usar, e quando ela acaba o macOS começa a comprimir e a usar swap, o que você sente como tudo ficando um pouco pior ao mesmo tempo.

Um app nativo que pega emprestados os frameworks do sistema, diagrama só o que está visível, mantém seus documentos como arquivos e deixa os servidores de linguagem rodarem nos próprios processos termina em torno de 63 MB sem ninguém ter otimizado nada. Isso não é uma história heroica de engenharia. É o resultado comum de não ter começado construindo um navegador.