O que tornava tudo pesado não era o Markdown, mas o motor web

Deixei um editor de Markdown aberto no notebook. Mesmo sem digitar nada, as ventoinhas começaram a girar.

No início, achei que fosse por causa do Markdown. Pensei que estivesse lento porque o documento era redesenhado continuamente.

Será que era mesmo?

Fiz a comparação nas mesmas condições

Deixei iguais o tamanho da tela, o método de renderização e o documento. Abri um documento de 7,5 KB e 113 linhas e não fiz nada durante 25 segundos. Ao digitar, também inseri os mesmos caracteres na mesma velocidade.

Em estado ocioso, o apostrophe, que renderiza a prévia com um motor web, usou 34,6% de CPU e 378 MB de memória. Havia cinco processos.

O protótipo, que renderizou o mesmo documento de forma inline, sem um motor web, usou 0,7% de CPU e 64 MB de memória. Havia apenas um processo.

Os dois estavam renderizando Markdown, mas os resultados foram muito diferentes.

Ao desativar apenas a prévia no apostrophe, o uso de CPU caiu para 7,0% e o de memória para 133 MB. O aplicativo e o toolkit continuaram os mesmos. A única coisa que mudou foi a maneira de renderizar a prévia.

Também medi um editor de texto que não renderiza Markdown de forma alguma. Ele usou 2,2% de CPU e 79 MB de memória.

O protótipo que renderizava Markdown era, na verdade, mais leve.

Foi então que ficou claro. O problema não era o Markdown.

Mesmo sem fazer nada, ele trabalhava 60 vezes por segundo

A causa estava no código que sincronizava a rolagem da prévia com a do texto principal.

Esse código não era executado apenas durante a rolagem. A cada 16 ms, um temporizador despertava e executava JavaScript no processo do WebKit. Quando a resposta chegava, o temporizador era programado novamente.

Mesmo sem ninguém tocar na janela, ele trabalhava cerca de 60 vezes por segundo.

Quando se usa um motor web, a área em que o documento é editado e a área em que a prévia é renderizada passam a existir em mundos diferentes. A maneira mais fácil de manter os dois estados sincronizados é verificá-los continuamente. Se o uso de CPU em estado ocioso não for medido separadamente, esse custo dificilmente aparece.

Durante a digitação, a diferença ficou ainda maior. O apostrophe usou 180% de CPU, enquanto o protótipo usou 41%.

Um deles precisava se comunicar até com o processo do navegador a cada tecla pressionada. O outro apenas reaplicava as tags às linhas alteradas.

Transformei os resultados das medições em princípios de design

O protótipo não tinha nenhuma otimização especial.

Os estilos foram aplicados ao texto por meio de tags. Várias edições foram agrupadas em uma única tarefa idle descartável, que desaparecia sozinha. O intervalo em que as tags eram reaplicadas foi limitado às linhas alteradas. Também foi usado apenas um processo.

Não foi uma questão de adicionar algo, mas de não incluir o que era desnecessário.

Depois disso, defini dois princípios de design.

Primeiro, não incluir um motor web nas dependências.

Segundo, se o documento não mudou e não há animações, não agendar frames, temporizadores nem ticks.

É difícil aplicar esses princípios mais tarde. Um motor web não é apenas uma biblioteca: ele muda a estrutura do aplicativo. Depois que é adicionado, removê-lo equivale a reconstruir o aplicativo. E, sem uma regra para os temporizadores, cada funcionalidade acaba ganhando o seu.

Em troca, foi preciso abrir mão do caminho mais fácil. Não era possível verificar alterações nos arquivos por polling, nem delegar as fórmulas a uma webview. Os layouts necessários precisavam ser criados diretamente.

Para que esses princípios não se percam, faço novas medições em dispositivos reais a cada versão.

Também é preciso ter cuidado ao interpretar os números

O experimento foi realizado com renderização por software. O uso de CPU fica mais alto do que em um ambiente com uma GPU real. Por isso, é preciso observar as proporções, e não os valores absolutos.

Os 0,7% de CPU em estado ocioso do protótipo também foram usados, em sua maior parte, para fazer o cursor piscar. Ao desativar o piscar, era difícil distinguir o valor de zero.

Isso não significa que todos os aplicativos baseados em motores web tenham o mesmo problema. Estes resultados se limitam ao apostrophe. Também há motores, como os da família Chromium, que reduzem o trabalho em estado ocioso.

O protótipo também não tinha muitos recursos. Não havia tabelas, fórmulas, exportação nem busca. O que pode ser comparado é apenas o custo de renderização.

Ainda assim, uma coisa ficou clara.

Não era o Markdown que gerava o custo. Eram o motor de renderização e o loop que nunca parava.

Quando se identifica a causa exata, a leveza deixa de ser um novo recurso e passa a ser uma subtração.