Ambiente
Todos os números desta página vêm de uma única máquina: o notebook em que o aplicativo é desenvolvido, com uma configuração comum de gráficos integrados. As versões para macOS e Windows estão em desenvolvimento; suas linhas aparecerão aqui quando existirem.
| Máquina | SO | Tela | Observações |
|---|---|---|---|
| Notebook, Intel i5-11300H, 23 GB, Iris Xe (Mesa 25.2) | Ubuntu 24.04, GNOME no X11 | 2560×1440 @ 60 Hz | Versão de lançamento, commit 04cf7dc |
Documento de teste: tools/perf/fixtures/doc100k.md (100 KB, 874 linhas) · 3 execuções, mediana · ponteiro fora da janela · barramento de sessão real.
Quadros ociosos
Afirmação: quando nada acontece, mote não desenha nada. Com o documento aberto no modo Live, o editor sem foco (para que o cursor não pisque) e sem entrada por 10 segundos (t = 5–15 s após a inicialização), contamos os snapshots do próprio editor: cada vez que GTK pede ao editor para desenhar.
| Plataforma | Quadros em 10 s | CPU, média | Método |
|---|---|---|---|
| Linux | 0 | 0.0% | Contagem de snapshots do editor por tools/perf/gate.sh |
Com o cursor piscando (o padrão quando a janela tem foco), a contagem é de um redesenho do editor por piscada — apenas o cursor muda — e para assim que a janela perde o foco. Essa piscada é o único temporizador que o aplicativo pode manter; não há nenhuma outra fonte repetitiva durante a ociosidade.
Latência de entrada
Afirmação: 9.7 ms da tecla ao pixel, no percentil 95. Tecla → processada: p95 0.29 ms. Tecla → pixel (inclui vsync): p95 9.7 ms. Medido dentro do processo por tools/perf/typing.sh, documento de 100 KB, modo Live.
Processada significa que o evento de entrada atualizou o documento e invalidou os layouts afetados; pixel significa o fim do snapshot seguinte, que espera o relógio de quadros e, portanto, tem como limite inferior o vsync (16.7 ms a 60 Hz). Em mais de 300 teclas, as duas distribuições foram p50 0.01 / p95 0.29 / máx. 0.48 ms e p50 2.6 / p95 9.7 / máx. 12.7 ms, medidas em 2026-09-02 na versão M3, um commit anterior à execução de validação abaixo; a execução de digitação ainda não está no diretório de resultados, então repita-a antes de confiar nela. O tempo de resposta da própria tela não está incluído; não o medimos.
Inicialização a frio
Afirmação: 211 ms da inicialização até a janela, com um arquivo de 100 KB aberto. A frio significa um processo novo, com o arquivo aberto na inicialização; nada é pré-aquecido e o cache de páginas não é alterado. O relógio começa em exec e para quando a janela é mapeada; a primeira pintura usa o mesmo relógio, interrompido no primeiro snapshot do documento pelo editor.
| Plataforma | exec → janela | Primeira pintura | Tamanho do binário | RSS (PSS) após carregar |
|---|---|---|---|---|
| Linux | 211 ms | 231 ms | 3.1 MB | 69 MB |
Método: tools/perf/gate.sh, a frio = processo novo, arquivo de 100 KB aberto na inicialização. O PSS é lido de /proc quinze segundos depois, quando o documento já foi disposto e o aplicativo ficou ocioso.
Mesma máquina, mesmo documento
Typora, Obsidian e MarkText, cada um aberto com o mesmo documento de 100 KB em seu modo de edição em linha (WYSIWYG do Typora, Live Preview do Obsidian, MarkText), na máquina acima e pelo mesmo script. A memória é o PSS de toda a árvore de processos doze segundos após a inicialização; a CPU ociosa é a CPU da árvore entre os segundos 5–10, com a janela em foco e sem entrada; a CPU durante a digitação é a CPU da árvore enquanto cerca de 150 caracteres são digitados, um a cada 30 ms. Sete execuções por editor, média, após descartar uma execução de aquecimento.
| Editor | Versão | PSS | CPU ociosa | CPU ao digitar | Processos |
|---|---|---|---|---|---|
| mote | pré-lançamento, commit b17c3bf | 78 MB | 0.0% | 10.9% | 1 |
| Typora | 1.14.9 | 453 MB | 0.1% | 102.6% | 8 |
| Obsidian | 1.12.7 | 361 MB | 0.8% | 152.5% | 7 |
| MarkText | 0.19.1 | 416 MB | 0.6% | 135.8% | 6 |
A CPU ociosa do Typora é tão baixa quanto a nossa — deixamos isso claro. Chromium reduz a atividade quando está realmente ocioso, então a coluna de ociosidade separa mote do Obsidian e do MarkText, não do Typora. É no uso de memória e no custo de digitação que os mecanismos divergem: um processo contra seis a oito, e um décimo da CPU por tecla. Os 78 MB aqui são maiores que os 69 MB acima porque representam toda a árvore de processos em outra sessão; o piso de GTK e Mesa varia cerca de uma dúzia de megabytes entre sessões.
MarkText foi executado com --no-sandbox (seu sandbox não inicia neste kernel); Obsidian foi executado em um vault novo, com apenas três plugins principais. Dados brutos: experiments/2026-09-03-apps-idle-startup/raw.csv.
Reproduza
O conjunto de testes, o corpus, os CSVs brutos e o JSON de resultados serão publicados com o beta em um repositório público de benchmarks no GitHub. tools/perf/gate.sh <binary> :1 3 executa a validação; tools/perf/bench-apps.sh, a comparação. Se seus números diferirem dos nossos em mais de 15 %, avise; publicaremos a divergência.
Última execução: validação em 2026-09-03 no commit 04cf7dc, comparação com b17c3bf; latência de digitação em 2026-09-02 na versão M3. Repetir a cada versão.