Números que mostramos como reproduzir.

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. A versão para Windows ainda não foi medida aqui e a versão para macOS está em desenvolvimento; suas linhas aparecerão aqui quando existirem.

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, mori 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.

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: 18.2 ms da tecla ao pixel, no percentil 95. Medido de fora do processo por tools/perf/index/e2e_latency.sh: uma tecla é injetada com XTest e a tela é consultada até a linha do cursor mudar. Documento de 100 KB, visão Live, 2560×1440 a 180 Hz. Em 119 toques: p50 14.1, p95 18.2, p99 19.1, máx. 20.4 ms.

O número cobre tudo que existe entre a tecla e o pixel: o toolkit, o compositor e a espera pelo próximo quadro. Essa espera cai em qualquer ponto entre zero e um intervalo de atualização — a 180 Hz, no máximo 5.6 ms e 2.8 em média —, por isso este número só pode ficar ao lado de outro editor medido na mesma taxa. O tempo de resposta do próprio monitor não está incluído; não medimos.

Inicialização a frio

Afirmação: 387 ms do início até a janela, com um arquivo de 100 KB aberto e nada em cache. Frio significa processo novo e page cache esvaziado: o binário, as bibliotecas e o arquivo vêm todos do disco. Com o cache quente — o caso do dia a dia — a mesma inicialização leva 259 ms. O relógio começa em exec e para quando a janela aparece; o primeiro desenho é o mesmo relógio parado na primeira renderização do documento.

Método: tools/perf/run-index.sh, frio = processo novo com o page cache esvaziado, arquivo de 100 KB aberto na inicialização, cinco rodadas. A memória é o PSS lido em /proc depois que o documento é diagramado e o app entra em repouso, menos a mesma leitura com um documento vazio — o que o documento custa para nós: 9.4 MB de 70 MB. O resto é o piso de toolkit e GPU que todo aplicativo GTK4 paga nesta máquina; ele varia com o driver, e por isso publicamos a nossa parte. O binário tem 6.1 MB. O primeiro desenho é lido do contador de quadros do próprio editor, que só a nossa build dev tem — os outros três mostram um traço em vez de um palpite.

Mesma máquina, mesmo documento

Typora, Obsidian e MarkText, cada um aberto no mesmo documento de 100 KB em sua visão de edição em linha (o WYSIWYG do Typora, a Live Preview do Obsidian, o MarkText), na máquina acima e na mesma rodada dos nossos números. A memória é o PSS de toda a árvore de processos depois que o documento é diagramado e o app entra em repouso; a CPU em repouso é a da árvore por trinta segundos com a janela em foco e sem digitação; a CPU de digitação é a da árvore enquanto cerca de 700 caracteres são digitados em ritmo humano, um a cada 150 ms.

Os motores se separam primeiro no repouso: com a janela aberta e nada acontecendo, o mori não usa CPU mensurável e acorda zero vezes por segundo, enquanto os três editores Electron ficam em 1,1–1,6 % e 29–75 despertares. Depois vem a digitação: uma fração de núcleo contra um terço a dois terços. E por fim a memória: um processo contra seis a nove, 70 MB contra 346–457.

O MarkText rodou com --no-sandbox (seu sandbox não inicia neste kernel); o Obsidian rodou em um diretório de dados separado. Dados brutos: tools/perf/results/2026-09-09-linux-myasus-180hz.json.

Reproduza

O harness e o arquivo de resultados estão no repositório; um repositório público com o corpus e os dados brutos está em preparação e ainda não tem data. tools/perf/run-index.sh roda todos os índices; tools/perf/check.sh valida o resultado contra os orçamentos. Se os seus números diferirem dos nossos em mais de 15 %, nos avise; publicamos a diferença.

Última execução: 2026-09-09, uma única rodada de tools/perf/run-index.sh contra o commit 183cc22 — todos os números desta página, os nossos e os dos outros editores, vêm dessa rodada. Refeito a cada versão.