Por que a digitação não fica lenta mesmo quando o documento cresce
Em notas curtas, qualquer editor é rápido. A diferença aparece quando o documento fica longo, e ela depende de o custo de uma única tecla acompanhar o tamanho da edição ou o tamanho do documento.
Notas curtas são rápidas em qualquer editor. A diferença aparece quando o documento fica longo.
Se, a cada tecla pressionada, o documento inteiro for relido e a tela for reorganizada, a digitação também ficará mais lenta à medida que o documento crescer. É por isso que um editor que funcionava bem em uma nota de dez linhas se torna frustrante em um documento de projeto com duas mil linhas.
O mote não tratou esse problema como uma questão de desempenho que poderia ser corrigida mais tarde. Desde o início, ele foi definido como um princípio de projeto que deveria ser respeitado.
Ao editar, releia e reorganize apenas o intervalo alterado. O documento inteiro só deve ser relido ao abrir um arquivo.
Releia apenas o que mudou
No Markdown, uma linha anterior pode alterar o significado das linhas seguintes. Se um bloco de código for aberto no início do documento, todo o conteúdo abaixo poderá se tornar código, e uma mesma frase será interpretada de maneira diferente dentro de uma lista ou de uma citação.
Por isso, o mote memoriza os “pontos seguros” em que a influência do conteúdo anterior certamente termina. Quando ocorre uma edição, ele começa a leitura no ponto seguro mais próximo e para no momento em que o conteúdo volta a se estabilizar.
Os blocos posteriores não são relidos. Se o número de linhas aumentou ou diminuiu, apenas suas posições são deslocadas. Assim, o custo passa a acompanhar o intervalo que realmente mudou, e não o documento inteiro.
O analisador segue o algoritmo linha a linha do CommonMark e passa em todos os 652 testes da especificação. Mas é fácil o processamento incremental produzir erros silenciosos. Por isso, aplicamos 3.600 edições aleatórias a documentos aleatórios e, após cada edição, comparamos o resultado com o obtido pela releitura do documento inteiro.
Essa verificação também encontrou um bug real. Ele ocorria quando o ponto seguro e a linha editada coincidiam exatamente.
Os princípios de desempenho são protegidos por verificações
A meta é um p95 de 4 ms entre o pressionamento de uma tecla e a conclusão do processamento pelo núcleo. Se esse tempo for ultrapassado, isso é tratado como um bug, e não como uma tarefa de melhoria.
Também não deixamos as regras apenas registradas em documentos. Uma verificação automática confirma que a reanálise completa só é usada ao abrir um arquivo. Ela também impede temporizadores ou trabalhos de quadro que se repetem durante o estado ocioso.
O desempenho também não é avaliado visualmente por uma pessoa. O harness digita teclas em uma tela real e mede a distribuição dos tempos de processamento. Em vez da média ou da mediana, observamos o p95. Isso porque o que frustra o usuário são os atrasos longos que aparecem ocasionalmente, mais do que a velocidade habitual.
As medições usam sempre o mesmo documento fixo.
doc100k.md, usado pelo harness, aberto no modo ao vivo. A linha de status exibe 96.513 caracteres e um tempo de leitura de 103 minutos.A tela também é atualizada apenas na medida necessária
Não bastava tornar incremental apenas o analisador.
O realce de sintaxe dos blocos de código ainda reprocessava todos os blocos a cada edição. Era a última tarefa que ficava mais lenta à medida que o documento crescia, independentemente do tamanho da edição.
Agora, o realce de sintaxe dos blocos que não foram modificados é reutilizado sem alterações. Os blocos posteriores à edição apenas mudam de posição conforme a variação no número de linhas.
Os blocos fora da tela não passam pelo processo de layout. Isso ocorre porque é preciso reduzir tanto o intervalo relido quanto o intervalo redesenhado para manter a velocidade mesmo em documentos longos.
Também há exceções
Há momentos em que é necessário reprocessar o documento inteiro.
Isso acontece ao abrir um arquivo ou quando o formato das quebras de linha muda. Se uma definição de referência de link for alterada, qualquer link no documento poderá mudar; por isso, o intervalo de atualização da tela também é ampliado para o documento inteiro.
Mesmo que o núcleo seja rápido, a tela precisa esperar pelo próximo quadro. Em uma tela de 60 Hz, o próprio intervalo entre quadros se torna um limite. Por isso, medimos separadamente o tempo de processamento do núcleo e o tempo até o resultado realmente aparecer na tela, sem colocar os dois números no mesmo eixo. É por isso que as duas linhas da capa são diferentes.
Um editor rápido não é um editor que faz tudo rapidamente.
É um editor que não faz o que não precisa ser feito.