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. Las versiones para macOS y Windows están 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, mote 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: 9.7 ms desde la pulsación hasta el píxel, en el percentil 95. Pulsación → procesada: p95 0.29 ms. Pulsación → píxel —incluye vsync—: p95 9.7 ms. Medido dentro del proceso mediante tools/perf/typing.sh, con un documento de 100 KB en la vista En vivo.

Procesada significa que el evento de entrada actualizó el documento e invalidó las disposiciones afectadas; píxel significa el final de la siguiente instantánea, que espera al reloj de fotogramas y, por tanto, está limitado inferiormente por vsync (16.7 ms a 60 Hz). En 300 pulsaciones, las dos distribuciones fueron p50 0.01 / p95 0.29 / máx. 0.48 ms y p50 2.6 / p95 9.7 / máx. 12.7 ms, medidas el 2026-09-02 en la compilación M3, con un commit anterior al de la prueba de control siguiente; la ejecución de escritura aún no está en el directorio de resultados, así que repítala antes de confiar en ella. No se incluye el tiempo de respuesta de la propia pantalla; no lo hemos medido.

Inicio en frío

Afirmación: 211 ms desde el inicio hasta la ventana, con un archivo de 100 KB abierto. En frío significa un proceso nuevo con el archivo abierto al iniciar; nada está precalentado y la caché de páginas se deja intacta. El reloj comienza en exec y se detiene cuando se mapea la ventana; para el primer dibujo se usa el mismo reloj, detenido en la primera instantánea del documento tomada por el editor.

Método: tools/perf/gate.sh, frío = proceso nuevo, archivo de 100 KB abierto al iniciar. El PSS se lee de /proc quince segundos después, una vez dispuesto el documento y con la aplicación en reposo.

Mismo equipo, mismo documento

Typora, Obsidian y MarkText se abrieron, cada uno, con el mismo documento de 100 KB en su vista de edición en línea —WYSIWYG de Typora, Live Preview de Obsidian y MarkText—, en el equipo anterior y mediante el mismo script. La memoria es el PSS de todo el árbol de procesos doce segundos después del inicio; la CPU en reposo es la del árbol durante los segundos 5–10, con la ventana enfocada y sin entrada; la CPU durante la escritura es la del árbol mientras se escriben unos 150 caracteres, uno cada 30 ms. Siete ejecuciones por editor, promedio, después de descartar una ejecución de calentamiento.

La CPU en reposo de Typora es tan baja como la nuestra —y así lo decimos—. Chromium reduce su actividad cuando está realmente en reposo, por lo que esa columna distingue a mote de Obsidian y MarkText, pero no de Typora. La diferencia entre los motores aparece en la memoria y el coste de escritura: un proceso frente a entre seis y ocho, y una décima parte de la CPU por pulsación. Los 78 MB indicados aquí superan los 69 MB anteriores porque corresponden a todo el árbol de procesos en otra sesión; el consumo base de GTK y Mesa varía en torno a una docena de megabytes entre sesiones.

MarkText se ejecutó con --no-sandbox —su entorno aislado no se inicia en este kernel—; Obsidian se ejecutó en un vault nuevo con solo tres complementos básicos. Datos sin procesar: experiments/2026-09-03-apps-idle-startup/raw.csv.

Reprodúzcalo

El conjunto de pruebas, el corpus, los CSV sin procesar y el JSON de resultados se publicarán con la beta en un repositorio público de pruebas en GitHub. tools/perf/gate.sh <binary> :1 3 ejecuta la prueba de control; tools/perf/bench-apps.sh, la comparación. Si sus cifras difieren de las nuestras en más de un 15 %, díganoslo; publicaremos la discrepancia.

Última ejecución: prueba de control del 2026-09-03 con el commit 04cf7dc, comparación con b17c3bf; latencia de escritura del 2026-09-02 en la compilación M3. Se repite con cada versión.