Por que divulgamos números em vez de apenas dizer que é leve
Não há nada para verificar quando se diz apenas que algo é leve. A mote definiu oito números para falar sobre si mesma e publica junto o método de medição, as condições e os dados brutos.
Editores de Markdown costumam ser apresentados assim.
Rápidos. Leves. Suaves.
Mas, quando faltam as condições dos números, eles não são diferentes de adjetivos. Quando a CPU em estado ocioso foi medida e por quanto tempo. De onde até onde o tempo de inicialização foi calculado. Isso porque números obtidos em condições diferentes não podem ser comparados.
Por isso, definimos em oito os indicadores de desempenho que a mote torna públicos. Para cada indicador, registramos o método e as condições de medição, as exclusões, as regras de comparação, os pontos de atenção e o orçamento. Também vinculamos cada um deles a um script de medição.
A documentação, os resultados e o código usam todos os mesmos nomes. Assim, é possível rastrear imediatamente de onde cada número veio.
Números precisam vir acompanhados de condições
A mote segue quatro princípios.
Para todas as medições, armazenamos juntos o valor, a unidade, a estatística, o tamanho da amostra e as amostras brutas. Resultados sem unidade são rejeitados na etapa de verificação.
Não registramos valores que não foram medidos. Se não for possível medir algo, deixamos o campo vazio e explicamos o motivo. Não o preenchemos com uma estimativa.
As comparações são feitas apenas na mesma máquina e na mesma sessão. Não colocamos lado a lado números obtidos em dias ou dispositivos diferentes.
Também publicamos as condições de medição junto com os números. Em especial, sempre registramos a taxa de atualização e o governador da CPU. Se essas condições forem diferentes, não é possível comparar corretamente a latência e o tempo de inicialização.
Não criamos novos métodos de medição.
A latência entre a entrada da tecla e a mudança na tela é medida exatamente com o método usado pelo Typometer de Pavel Fatin. A tecla é pressionada de fora do aplicativo e verificamos até o momento em que o pixel muda. O tempo de inicialização foi dividido em etapas, como no VS Code, distinguindo entre inicialização a frio e inicialização a quente.
O princípio de que a latência deve ser medida de ponta a ponta, e não dentro do framework, veio de um artigo de Dan Luu.
Comparamos diretamente nas mesmas condições
Para o desempenho dos aplicativos concorrentes, não citamos números de outros lugares. Fizemos as medições diretamente no mesmo notebook.
Abrimos o mesmo documento de 100 KB e executamos cada aplicativo sete vezes com o mesmo script. Todos usaram a tela de edição em linha, e a posição do ponteiro também foi mantida igual.
O uso de memória de todos os processos foi o seguinte.
- mote: 78 MB
- Typora: 453 MB
- Obsidian: 361 MB
- MarkText: 416 MB
Durante a digitação, o uso de CPU, considerando um único núcleo, foi de 10,9%, 103%, 152% e 136%. O número de processos foi, respectivamente, 1, 8, 7 e 6.
O uso de memória da mote foi de 4,6 a 5,8 vezes menor. O uso de CPU durante a digitação foi de 9,4 a 14 vezes menor.
A memória foi calculada usando PSS, não RSS. O RSS pode contar mais de uma vez a memória compartilhada entre vários processos. O PSS divide a memória compartilhada de acordo com o número de processos. É também o mesmo método usado pelo monitor do sistema.
Também mantivemos os números desfavoráveis como estavam
Quando os aplicativos ficavam apenas abertos, o uso de CPU era de 0,0% na mote, 0,1% no Typora, 0,8% no Obsidian e 0,6% no MarkText.
O Typora também quase não usava CPU quando estava ocioso. Portanto, não podemos apresentar o fato de que “não faz nada quando fica aberto” como uma vantagem sobre o Typora.
O shell web usou 3,6%, sendo, na verdade, pior que o Typora.
Eliminar os temporizadores repetitivos internos do aplicativo continua sendo importante. Mas um princípio que deve ser seguido e uma vantagem competitiva são questões diferentes.
Não comparamos os quadros em estado ocioso com os aplicativos concorrentes. A meta da mote é de 0 quadro durante 10 segundos, mas os outros aplicativos não têm um contador de quadros que possa ser verificado da mesma maneira.
Por isso, deixamos vazios os campos dos aplicativos concorrentes. Um campo vazio não significa zero.
Se não for possível comparar, não comparamos
Também verificamos se o arquivo original permanece inalterado quando é aberto e salvo sem nenhuma modificação.
A mote verifica 652 exemplos do CommonMark. Também abrimos e salvamos novamente todos os documentos do repositório e verificamos se eles são idênticos byte por byte. Se houver qualquer diferença, consideramos isso um bug de perda de dados, não um problema de desempenho.
Não registramos resultados dos aplicativos concorrentes. Isso porque era difícil automatizar o processo de salvamento nas mesmas condições.
Antes das medições, também verificamos o estado da máquina. Não iniciamos uma medição se houver uma compilação em andamento. O navegador só impede a medição quando realmente está usando muita CPU. A média de carga, a porcentagem de CPU ociosa, os critérios de decisão e os valores no momento da medição são todos registrados nos resultados.
Essa regra surgiu depois de enfrentarmos uma falha.
Medimos o tempo de inicialização com um navegador que consumia muita CPU aberto, e isso fez parecer que o desempenho havia piorado. Ao alternarmos as medições entre o commit anterior e o atual sob a mesma carga, descobrimos que a causa não era uma regressão no código, mas a carga da máquina.
Desde então, não avaliamos o tempo de inicialização observando apenas um único valor absoluto.
Se ultrapassar o orçamento, não pode ser mesclado
O orçamento de desempenho não é apenas uma meta registrada na documentação. É um critério que precisa ser cumprido para que o build seja aprovado.
Os critérios são divididos em hard e report.
hard corresponde aos itens cujos números foram definidos em um documento de decisão. Se qualquer um deles ultrapassar o limite, a verificação falha. Também não há aprovação separada de exceções.
report corresponde aos itens para os quais ainda não há evidências suficientes ou que são muito afetados pelas limitações da plataforma. Os valores são registrados, mas não impedem o build.
Se impedirmos o build com base em números sem evidências suficientes, as pessoas passarão a evitar a própria medição. Por isso, usamos como gate apenas critérios bem fundamentados.
Os scripts de medição, os arquivos CSV originais e os resultados em JSON são mantidos juntos no repositório. Ao executar os mesmos scripts nas mesmas condições, é possível recriar a tabela. Também estamos preparando a publicação das ferramentas de medição e dos documentos de teste em um repositório público de benchmarks.
Escolher apenas os números bons não é transparência.
Mostrar junto o que foi medido e como, quais eram as condições e até mesmo o que não pôde ser medido. É assim que a mote torna seus números públicos.