Por qué publicamos cifras en vez de decir que es «ligero»

Los editores de Markdown suelen presentarse así.

Rápidos. Ligeros. Fluidos.

Pero, si a las cifras les faltan las condiciones, no son distintas de los adjetivos. Cuándo se midió el uso de CPU en reposo y durante cuánto tiempo. Desde qué punto hasta qué punto se calculó el tiempo de inicio. Porque no se pueden comparar cifras obtenidas en condiciones diferentes.

Por eso decidimos que mote publicaría ocho métricas de rendimiento. Para cada una registramos el método y las condiciones de medición, las exclusiones, las reglas de comparación, las precauciones y el presupuesto. También enlazamos cada una con su script de medición.

La documentación, los resultados y el código usan todos los mismos nombres. Así se puede rastrear de inmediato de dónde salió cada cifra.

Las cifras deben ir acompañadas de sus condiciones

mote sigue cuatro principios.

Guardamos junto con todas las mediciones el valor y la unidad, la estadística, el tamaño de la muestra y las muestras originales. Los resultados sin unidad se rechazan durante la fase de comprobación.

No anotamos valores que no hayamos medido. Si algo no se puede medir, dejamos el campo vacío e indicamos el motivo. No lo rellenamos con estimaciones.

Solo hacemos comparaciones en la misma máquina y durante la misma sesión. No colocamos una al lado de otra cifras obtenidas en días o dispositivos diferentes.

También publicamos las condiciones de medición junto con las cifras. En particular, siempre indicamos la frecuencia de refresco y el gobernador de CPU. Si estas condiciones son distintas, no se pueden comparar correctamente la latencia ni el tiempo de inicio.

No inventamos métodos de medición nuevos.

La latencia desde la pulsación de una tecla hasta el cambio de la pantalla se mide exactamente con el método que emplea Typometer, de Pavel Fatin. Se introduce la tecla desde fuera de la aplicación y se comprueba cuánto tarda en cambiar un píxel. Dividimos el tiempo de inicio en etapas, como hace VS Code, y distinguimos entre arranque en frío y arranque en caliente.

El principio de que la latencia debe medirse de extremo a extremo, y no dentro del framework, procede de un artículo de Dan Luu.

Hicimos comparaciones directas en las mismas condiciones

Para el rendimiento de las aplicaciones de la competencia no citamos cifras de otras fuentes. Lo medimos directamente en el mismo portátil.

Abrimos el mismo documento de 100 KB y ejecutamos cada aplicación siete veces con el mismo script. En todas usamos la vista de edición en línea y colocamos el puntero en la misma posición.

El uso de memoria de todos los procesos fue el siguiente.

• mote: 78MB
• Typora: 453MB
• Obsidian: 361MB
• MarkText: 416MB

El uso de CPU durante la escritura, tomando un núcleo como referencia, fue del 10.9%, 103%, 152% y 136%, respectivamente. El número de procesos fue, respectivamente, 1, 8, 7 y 6.

El uso de memoria de mote fue entre 4.6 y 5.8 veces menor. El uso de CPU durante la escritura fue entre 9.4 y 14 veces menor.

Calculamos la memoria mediante PSS, no RSS. RSS puede contar varias veces la memoria compartida por varios procesos. PSS reparte la memoria compartida entre el número de procesos. También es el método que utilizan los monitores del sistema.

También conservamos intactas las cifras desfavorables

Cuando las aplicaciones permanecían abiertas sin hacer nada, el uso de CPU era del 0.0% para mote, del 0.1% para Typora, del 0.8% para Obsidian y del 0.6% para MarkText.

Typora tampoco utilizaba prácticamente nada de CPU en reposo. Por tanto, no podemos presentar el hecho de que «no hace nada cuando se deja abierta» como una ventaja frente a Typora.

El shell web utilizó un 3.6%, por lo que fue incluso peor que Typora.

Eliminar los temporizadores repetitivos del interior de la aplicación sigue siendo importante. Pero los principios que deben respetarse y las ventajas competitivas son cuestiones distintas.

No comparamos los fotogramas en reposo con los de las aplicaciones de la competencia. El objetivo de mote es producir 0 fotogramas durante 10 segundos, pero las demás aplicaciones no tienen un contador de fotogramas que permita comprobarlo de la misma manera.

Por eso dejamos vacías las casillas de las aplicaciones de la competencia. Una casilla vacía no significa 0.

Si no se puede comparar, no lo comparamos

También comprobamos si el archivo original permanece intacto cuando se abre y se guarda sin modificaciones.

mote comprueba los 652 ejemplos de CommonMark. También abre todos los documentos del repositorio, vuelve a guardarlos y verifica que sean idénticos byte por byte. Si cambia siquiera uno, no lo consideramos un problema de rendimiento, sino un error de pérdida de datos.

No anotamos resultados para las aplicaciones de la competencia. La razón es que resultaba difícil automatizar el proceso de guardado en las mismas condiciones.

Antes de medir, también comprobamos el estado de la máquina. Si hay una compilación en curso, no iniciamos la medición. Solo impedimos que el navegador siga ejecutándose cuando realmente está consumiendo mucha CPU. La carga media, el porcentaje de CPU inactiva, los criterios de decisión y los valores registrados en el momento de la medición quedan incluidos en los resultados.

Esta regla surgió después de sufrir un fallo.

Medimos el tiempo de inicio mientras teníamos abierto un navegador que consumía mucha CPU y pareció que el rendimiento había empeorado. Al medir alternadamente el commit anterior y el actual bajo la misma carga, comprobamos que la causa no era una regresión del código, sino la carga de la máquina.

Desde entonces, no evaluamos el tiempo de inicio fijándonos únicamente en un valor absoluto.

Si se supera el presupuesto, no se puede hacer merge

El presupuesto de rendimiento no es un objetivo que solo figure en la documentación. Es un criterio que debe cumplirse para que la compilación tenga éxito.

Los criterios se dividen en hard y report.

hard corresponde a elementos cuyas cifras están fijadas en un documento de decisión. Si uno solo supera el límite, la comprobación falla. Tampoco existe un proceso separado para aprobar excepciones.

report corresponde a elementos para los que aún no hay pruebas suficientes o que se ven muy afectados por las limitaciones de la plataforma. Sus valores se registran, pero no bloquean la compilación.

Si se bloquea la compilación basándose en cifras que carecen de pruebas suficientes, la gente empieza a evitar las propias mediciones. Por eso solo usamos como puerta de control los criterios que están bien fundamentados.

Conservamos juntos en el repositorio los scripts de medición, los CSV originales y los resultados en JSON. Al ejecutar el mismo script en las mismas condiciones, se puede volver a generar la tabla. También estamos preparando la publicación de las herramientas de medición y los documentos de prueba en un repositorio público de benchmarks.

Elegir únicamente las cifras favorables no es transparencia.

Mostrar conjuntamente qué se midió y cómo, en qué condiciones y qué cosas no se pudieron medir. Así es como mote publica sus cifras.