La causa de la pesadez no era Markdown, sino el motor web

Dejé abierto un editor de Markdown en el portátil. Aunque no estaba escribiendo nada, el ventilador empezó a girar.

Al principio pensé que era por Markdown. Creía que iba lento porque estaba redibujando el documento continuamente.

¿De verdad era así?

Hice la comparación en las mismas condiciones

Igualé el tamaño de la pantalla, el método de renderizado y el documento. Abrí un documento de 7,5 KB y 113 líneas y no hice nada durante 25 segundos. Al escribir, también introduje los mismos caracteres a la misma velocidad.

El uso de CPU en reposo de apostrophe, que renderiza la vista previa mediante un motor web, fue del 34,6 %, y el consumo de memoria fue de 378 MB. Además, tenía cinco procesos.

El prototipo, que renderizaba el mismo documento en línea sin un motor web, utilizó un 0,7 % de CPU y 64 MB de memoria. Tenía un solo proceso.

Ambos estaban renderizando Markdown, pero los resultados fueron muy diferentes.

Al desactivar únicamente la vista previa en apostrophe, el uso de CPU bajó al 7,0 % y la memoria a 133 MB. Tanto la aplicación como el toolkit seguían siendo los mismos. Lo único que había cambiado era la forma de renderizar la vista previa.

También medí un editor de texto que no renderizaba Markdown en absoluto. Utilizó un 2,2 % de CPU y 79 MB de memoria.

El prototipo que renderizaba Markdown era, de hecho, más ligero.

Entonces quedó claro. El problema no era Markdown.

Trabajaba 60 veces por segundo aunque no hiciera nada

La causa estaba en el código que sincronizaba el desplazamiento de la vista previa con el cuerpo del documento.

Este código no se ejecutaba únicamente al desplazarse. Cada 16 ms, un temporizador se activaba y ejecutaba JavaScript en el proceso de WebKit. Cuando llegaba la respuesta, volvía a programar el temporizador.

Aunque nadie tocara la ventana, trabajaba unas 60 veces por segundo.

Cuando se utiliza un motor web, el área donde se edita el documento y el área donde se renderiza la vista previa pasan a ser dos mundos distintos. La forma más sencilla de mantener sincronizados ambos estados es comprobarlos continuamente. Si no se mide por separado la CPU en reposo, este coste no resulta fácil de ver.

Al escribir, la diferencia se hizo aún mayor. apostrophe utilizó un 180 % de CPU y el prototipo un 41 %.

Uno de ellos llegaba hasta el proceso del navegador cada vez que se pulsaba una tecla. El otro solo volvía a aplicar las etiquetas a las líneas modificadas.

Convertí los resultados de las mediciones en principios de diseño

El prototipo no tenía ninguna optimización especial.

Los estilos se aplicaban mediante etiquetas sobre el texto. Varias ediciones se agrupaban en una única tarea idle de un solo uso que desaparecía por sí sola. El ámbito en el que se volvían a aplicar las etiquetas se limitaba a las líneas modificadas. También utilizaba un único proceso.

No se trataba de añadir algo, sino de no incluir lo que no era necesario.

Después establecí dos principios de diseño.

Primero, no incluir un motor web entre las dependencias.

Segundo, si el documento no cambia y no hay animaciones, no programar frames, temporizadores ni ticks.

Es difícil aplicar estos principios más adelante. Un motor web no es una simple biblioteca, sino que cambia la estructura de la aplicación. Una vez incorporado, eliminarlo equivale a rehacer la aplicación. Y si no existen reglas para los temporizadores, se añade uno nuevo con cada funcionalidad.

A cambio, tuve que renunciar al camino fácil. No podía comprobar los cambios en los archivos mediante polling ni delegar las fórmulas en una webview. Tuve que crear directamente el layout necesario.

Para evitar que estos principios se diluyan, vuelvo a realizar las mediciones en un dispositivo real con cada versión.

También hay que tener cuidado al interpretar las cifras

El experimento se realizó con renderizado por software. El uso de CPU resulta más alto que en un entorno con una GPU real. Por eso hay que fijarse en las proporciones más que en los valores absolutos.

Incluso el 0,7 % de CPU en reposo del prototipo se debía principalmente al parpadeo del cursor. Al desactivar el parpadeo, resultaba difícil distinguirlo de cero.

Esto no significa que todas las aplicaciones basadas en motores web sufran el mismo problema. Estos resultados se limitan a apostrophe. También hay motores, como los de la familia Chromium, que reducen el trabajo cuando están en reposo.

El prototipo tampoco tenía muchas funcionalidades. No incluía tablas, fórmulas, exportación ni búsqueda. Lo que puede compararse llega únicamente hasta el coste del renderizado.

Aun así, una cosa quedó clara.

Lo que generaba el coste no era Markdown. Eran el motor de renderizado y el bucle que nunca se detenía.

Cuando se identifica la causa exacta, la ligereza deja de ser una nueva funcionalidad y se convierte en una resta.