Cómo logramos que no use CPU cuando simplemente está abierto

El editor es la aplicación que permanece abierta durante más tiempo en el portátil. Pero el tiempo que se pasa escribiendo realmente no es largo. La mayor parte del tiempo permanece abierto en silencio mientras haces otras cosas.

Por eso mote estableció un principio.

Si el documento no cambia y no hay ninguna animación, no hace nada.

No hay fotogramas programados, temporizadores repetitivos ni comprobaciones periódicas. No es una optimización, sino un principio de diseño que debe respetarse antes que cualquier funcionalidad.

Si no pasa nada, también hay 0 fotogramas

Es difícil saber si una aplicación está inactiva basándose únicamente en el uso de CPU. Esto se debe a que el valor fluctúa en cada medición y, al redondearlo, fácilmente se convierte en 0.

Por eso mote mira primero el número de fotogramas. Si no hay cambios en el documento durante los 10 segundos posteriores a la apertura de la ventana, el número de fotogramas dibujados debe ser exactamente 0. Se cuentan directamente dentro de la aplicación y, si se dibuja siquiera uno, el código no se integra.

Aunque haya 0 fotogramas, no se puede bajar la guardia. Porque los hilos pueden seguir despertándose en segundo plano. También se registra cuántas veces por segundo se despiertan todos los hilos del proceso. Como todavía se están recopilando valores de referencia, este dato por sí solo no bloquea el desarrollo.

La única excepción es el parpadeo del cursor. No utiliza un temporizador repetitivo: después de parpadear una vez, vuelve a programar la siguiente acción. Si la ventana pierde el foco, se detiene de inmediato. El presupuesto de CPU en reposo, incluido el cursor, es del 0,3 %.

El rendimiento en reposo no se analiza de forma aislada. Si se retrasa el dibujado, es fácil conseguir 0 fotogramas, pero los caracteres introducidos pueden tardar en aparecer. Por eso se comprueban al mismo tiempo la latencia de entrada del teclado, la velocidad de inicio y la memoria. Si se supera siquiera uno de los límites, el código no se integra.

Una vez en el código y otra en un dispositivo real

Los principios se desdibujan con el tiempo. Por eso se comprueban dos veces.

Primero se inspecciona el código. Se buscan automáticamente temporizadores repetitivos, ticks que nunca terminan, sondeos que alternan continuamente entre dormir y despertar, y código que vuelve a leer innecesariamente archivos completos. Si se encuentra alguno, la CI se detiene ahí. Si se trata de una excepción imprescindible, justo encima del código se debe explicar por qué termina la tarea.

Después se mide en un dispositivo real. Para ello se respetan cuatro condiciones.

La medición se realiza en una pantalla real con GPU. El puntero se deja fuera de la ventana. Se utiliza un bus de sesión real y los fotogramas se cuentan justo en el momento en que se dibujan.

Estas condiciones surgieron a partir de fallos. En una ocasión se generaron 150 fotogramas en reposo solo porque el puntero estaba sobre la ventana. En una sesión aislada, el inicio se retrasó varios segundos porque el toolkit esperaba una respuesta. Y cuando se utilizó un contador de fotogramas que informaba con retraso, los fotogramas de la pantalla de inicio llegaron a mezclarse con el intervalo de reposo.

La memoria tampoco se evalúa por su valor absoluto. Esto se debe a que la memoria ocupada por el toolkit y el controlador gráfico puede variar en decenas de MB según el entorno.

En su lugar, se utiliza un documento vacío como referencia. Solo se comprueba cuánto más se utiliza al abrir un documento en comparación con uno vacío. En una medición reciente, el documento vacío utilizó 116 MB y el documento de 100 KB, 120 MB. La memoria adicional utilizada por mote fue de 4 MB, dentro del presupuesto de 8 MB.

No se midió así desde el principio. Hubo una ocasión en la que parecía que se había superado el presupuesto de memoria, pero resultó que no había aumentado la memoria de la aplicación, sino la memoria base del entorno de ejecución. Desde aquel día se empezó a medir, en lugar del valor absoluto, «la cantidad añadida por nuestra funcionalidad».

Durante el desarrollo, también se muestra en pantalla el número de temporizadores activos. Si no es 0, se puede saber de inmediato antes de hacer commit.

El guardado automático también sigue este principio. Solo se configura un temporizador una vez cuando el documento cambia y se elimina al terminar el guardado. No se despierta periódicamente para comprobar: «¿Ha cambiado algo?».

No son cifras para vencer a la competencia

Al principio se quería presentar el rendimiento en reposo como una ventaja sobre Typora. Pero al medirlo directamente, resultó que no era así.

En el mismo dispositivo y bajo las mismas condiciones, el uso de CPU en reposo de Typora fue del 0,1 %. Era prácticamente igual que mote. Las aplicaciones en las que sí se confirmó una diferencia fueron Obsidian, con un 0,8 %, y MarkText, con un 0,6 %.

También hubo una afirmación incorrecta. Durante un tiempo, la documentación decía: «Typora utiliza CPU cuando se deja abierto». El 34,6 % utilizado como fundamento no correspondía a Typora, sino a una medición de apostrophe. Tras volver a comprobarlo, la frase se corrigió de inmediato.

Los 0 fotogramas en reposo no son una afirmación dirigida contra la competencia. Son una disciplina que mote se impone a sí mismo. Porque, si no hay tareas ejecutándose repetidamente, siempre se puede explicar qué está haciendo la aplicación en ese momento.

También hay cosas a las que se ha renunciado por este principio

A menudo no se pueden utilizar los métodos más cómodos.

En lugar de comprobar periódicamente si el archivo ha cambiado desde fuera, hay que recibir las notificaciones de cambios del sistema operativo. En lugar de delegar las fórmulas a una webview, se creó directamente un motor de diseño. Tampoco se puede permitir que las animaciones se ejecuten continuamente. Todo movimiento tiene un principio y un final y, cuando termina, debe detenerse por completo.

No diremos que la batería dura varias horas más. Porque es una cifra que no se ha medido. Lo que sí se ha comprobado es el número de fotogramas, el uso de CPU e incluso el número de veces que se despertaron los hilos.

No hacer nada cuando no pasa nada.

En mote no es una funcionalidad, sino el principio que todas las funcionalidades deben superar.