Cifras que puede reproducir.

Entorno

Todas las cifras de esta página proceden de un solo equipo: el portátil en el que se desarrolla la aplicación, con una configuración corriente de gráficos integrados. La versión para Windows aún no se ha medido aquí y la de macOS está en desarrollo; sus filas aparecerán aquí cuando existan.

Documento de prueba: tools/perf/fixtures/doc100k.md (100 KB, 874 líneas) · 3 ejecuciones, mediana · puntero fuera de la ventana · bus de sesión real.

Fotogramas en reposo

Afirmación: cuando no ocurre nada, mori no dibuja nada. Con el documento abierto en la vista En vivo, el editor sin foco —para que el cursor no parpadee— y sin entradas durante 10 segundos (t = 5–15 s tras el inicio), contamos las instantáneas del propio editor: cada vez que GTK le pide que dibuje.

Con el parpadeo del cursor activado —el valor predeterminado cuando la ventana tiene el foco—, hay un redibujado del editor por cada parpadeo: solo cambia el cursor. Se detiene en cuanto la ventana pierde el foco. Ese parpadeo es el único temporizador que la aplicación puede mantener; no hay ninguna otra fuente repetitiva en reposo.

Latencia de entrada

Afirmación: 18.2 ms de la tecla al píxel, en el percentil 95. Medido desde fuera del proceso por tools/perf/index/e2e_latency.sh: se inyecta una tecla con XTest y se sondea la pantalla hasta que cambia la línea del cursor. Documento de 100 KB, vista Live, 2560×1440 a 180 Hz. En 119 pulsaciones: p50 14.1, p95 18.2, p99 19.1, máx. 20.4 ms.

La cifra abarca todo lo que hay entre la tecla y el píxel: el toolkit, el compositor y la espera hasta el siguiente fotograma. Esa espera cae en cualquier punto entre cero y un intervalo de refresco —a 180 Hz, como mucho 5.6 ms y 2.8 de media—, por eso solo puede ponerse junto a otro editor medido al mismo refresco. El tiempo de respuesta de la pantalla no está incluido; no lo hemos medido.

Inicio en frío

Afirmación: 387 ms del arranque a la ventana, con un archivo de 100 KB abierto y nada en caché. En frío significa proceso nuevo y caché de páginas vaciada: el binario, las bibliotecas y el archivo salen del disco. Con la caché caliente —el caso de cada día— ese mismo arranque tarda 259 ms. El reloj empieza en exec y para cuando aparece la ventana; el primer pintado es el mismo reloj detenido en el primer dibujo del documento.

Método: tools/perf/run-index.sh, en frío = proceso nuevo con la caché de páginas vaciada, archivo de 100 KB abierto al arrancar, cinco pasadas. La memoria es el PSS leído en /proc una vez maquetado el documento y con la aplicación en reposo, menos la misma lectura con un documento vacío: lo que nos cuesta el documento, 9.4 MB de 70 MB. El resto es el suelo de toolkit y GPU que paga toda aplicación GTK4 en esta máquina; se mueve con el controlador, y por eso publicamos nuestra parte. El binario ocupa 6.1 MB. El primer pintado se lee del contador de fotogramas del propio editor, que solo tiene nuestra compilación dev; los otros tres muestran un guion en vez de una estimación.

Mismo equipo, mismo documento

Typora, Obsidian y MarkText, cada uno abierto con el mismo documento de 100 KB en su vista de edición en línea (el WYSIWYG de Typora, la Live Preview de Obsidian, MarkText), en la máquina de arriba y en la misma ejecución que nuestras cifras. La memoria es el PSS de todo el árbol de procesos una vez maquetado el documento y con la aplicación en reposo; la CPU en reposo es la del árbol durante treinta segundos con la ventana enfocada y sin entrada; la CPU de escritura es la del árbol mientras se teclean unos 700 caracteres a ritmo humano, uno cada 150 ms.

Donde primero se separan los motores es en reposo: con la ventana abierta y sin hacer nada, mori no usa CPU medible y se despierta cero veces por segundo, mientras los tres editores Electron se quedan en 1.1–1.6 % y 29–75 despertares. Después, al escribir: una fracción de núcleo frente a un tercio o dos tercios. Y por último la memoria: un proceso frente a seis o nueve, 70 MB frente a 346–457.

MarkText se ejecutó con --no-sandbox (su sandbox no arranca en este kernel); Obsidian se ejecutó en un directorio de datos aparte. Datos en bruto: tools/perf/results/2026-09-09-linux-myasus-180hz.json.

Reprodúzcalo

El arnés y el archivo de resultados están en el repositorio; un repositorio público con el corpus y los datos en bruto está en preparación y aún no tiene fecha. tools/perf/run-index.sh ejecuta todos los índices; tools/perf/check.sh valida el resultado frente a los presupuestos. Si tus números difieren de los nuestros en más de un 15 %, dínoslo; publicamos la discrepancia.

Última ejecución: 2026-09-09, una sola pasada de tools/perf/run-index.sh contra el commit 183cc22: cada cifra de esta página, la nuestra y la de los demás editores, sale de esa pasada. Se repite en cada versión.