63 MB: lo que cuesta un editor de código en Mac cuando no es un navegador

Un editor es la aplicación que nunca se cierra. Se queda todo el día detrás del navegador, del correo y de la videollamada, guardando tus frases a medio escribir. Cueste lo que cueste, lo cuesta todo el tiempo, y lo cuesta en la misma máquina en la que además querías compilar algo.

Así que medimos MeatPad en lugar de suponerlo, en un Mac de trabajo normal con todo lo demás funcionando.

Los números

Tres escenarios, una máquina, una tarde:

MeatPad 0.10.2 · macOS 26.5.2 · Apple silicon

ventana de notas abierta, 19 h            63 MB    pico 83 MB
proyecto de 2.721 archivos, 6 pestañas   108 MB    pico 131 MB
un solo archivo de texto de 6,3 MB      1500 MB    ver la sección honesta

VS Code 1.130.0, misma carpeta, mismos 6 archivos
                                         710 MB    repartidos en 8 procesos

La fila del medio es la que importa, porque es la configuración de trabajo: un repositorio real con árbol de archivos, seis pestañas abiertas, resaltado de sintaxis, búsqueda en todo el proyecto y autocompletado activos. Se asienta en 108 MB y ahí se queda. El pico de 131 MB es la primera pasada por el proyecto, que construye el índice de identificadores para el autocompletado, y esa memoria se devuelve enseguida.

La fila de VS Code se hizo como contraste, no como veredicto: un directorio de usuario nuevo, sin extensiones instaladas, la misma carpeta y los mismos seis archivos, medido un minuto después del arranque. Hace muchísimo más que MeatPad, y buena parte de esa diferencia es el ecosistema de extensiones que mucha gente quiere con razón. La comparación habla del suelo, no de quién gana.

Compruébalo tú mismo, y desconfía del número equivocado

Dos herramientas de tu Mac se contradicen aquí, y solo una tiene razón. Mientras MeatPad informaba de 63 MB, ps decía 147 MB para el mismo proceso en el mismo instante:

$ ps -o rss= -p $(pgrep -x MeatPad)
  150304

$ footprint -p $(pgrep -x MeatPad)
    phys_footprint: 63 MB
    phys_footprint_peak: 83 MB

El resident set size cuenta cada página mapeada en el proceso, incluidas las páginas compartidas, de solo lectura y de copia en escritura de AppKit, SwiftUI, CoreText y el resto del sistema. Esas páginas residen una sola vez para todo el Mac y no se le cobran a nadie. La huella física cuenta solo aquello de lo que este proceso es realmente responsable, que es además el número que muestra el Monitor de Actividad en su columna de Memoria. Cuando alguien cite una cifra de memoria de una app nativa de Mac, pregúntale cuál de las dos midió.

Razón uno: dentro del proceso no hay ningún navegador

MeatPad es una aplicación nativa: Swift, AppKit y SwiftUI, 92 archivos de código y unas quince mil quinientas líneas incluyendo su propio paquete de framework. No hay Chromium, ni entorno de ejecución de JavaScript, ni proceso de Node, ni anfitrión de extensiones, ni copia privada de un kit de interfaz dentro del paquete.

Ese es todo el truco de los primeros cien megabytes. Un editor construido sobre una pila web tiene que llevarse un navegador al trabajo, y un navegador es un sistema operativo con opiniones propias: su motor de maquetación, su recolector de basura, un proceso por ventana, su copia de todo. Antes de dibujar un solo carácter de tu código ya lo ha pagado entero. Una app nativa toma prestados el motor de maquetación, el motor de texto y el kit de interfaz de la máquina, donde ya estaban cargados para el Finder.

Razón dos: el editor maqueta las líneas que puedes ver

La maquetación del texto es donde los editores se tuercen en silencio. Medir cada línea de un documento largo, con la tipografía y el ancho exactos, para que una barra de desplazamiento tenga la altura correcta, es muchísimo trabajo antes de enseñarle nada a nadie.

MeatPad dibuja mediante STTextView sobre TextKit 2, la pila de texto actual de Apple, que trabaja por área visible. Maqueta los fragmentos que están en pantalla y un poco más allá, y los olvida en cuanto salen. Abrir un archivo es leerlo y dibujar una pantalla. El coste del resto del documento se aplaza hasta que te desplazas hasta él, y se libera cuando te alejas.

Razón tres: tus notas son archivos en el disco, no una base de datos en memoria

Cada nota es un archivo de texto corriente con un pequeño JSON al lado. La aplicación no carga un espacio de trabajo en memoria para vivir ahí. Solo los documentos que realmente tienes abiertos guardan su texto, y cerrar una ventana lo devuelve.

El mismo instinto recorre las funciones de proyecto:

• El árbol de archivos hace primero una lectura superficial, de un solo nivel, para que la ventana se dibuje al instante, y cambia al árbol completo cuando está listo.
• La búsqueda en todo el proyecto lee los archivos del disco en paralelo en el momento de buscar. No hay ningún índice de búsqueda persistente ocupando memoria entre búsquedas, porque el disco es rápido y tu proyecto no es tan grande.
• El índice de autocompletado guarda recuentos de identificadores por archivo en vez del contenido de los archivos, y se salta todo lo que pase de cuatro megabytes.
• El resaltado de sintaxis es tree-sitter: analizadores compactos escritos en C, un árbol por documento abierto, reanalizado de forma incremental mientras escribes en lugar de reconstruido.

Razón cuatro: la inteligencia cara vive en otro proceso

La inteligencia de un editor es realmente cara. Un servidor de lenguaje mantiene un modelo semántico de todo tu proyecto, y para una base de código grande en Rust o Swift ese modelo empequeñece cualquier cosa que un editor haga con texto.

MeatPad no aloja ese trabajo. Habla el Language Server Protocol con servidores ya instalados en tu máquina, SourceKit-LSP, rust-analyzer, Pyright, cada uno en su propio proceso, arrancado al abrir un proyecto y terminado al cerrarlo. Lo que cueste el modelo semántico se le cobra al servidor, se ve con su propio nombre en el Monitor de Actividad y se recupera en cuanto cierras el proyecto. El editor guarda los mensajes, no el modelo. Si no hay ningún servidor instalado, el autocompletado recurre a los identificadores del proyecto abierto y todo lo demás sigue funcionando.

Por eso los números de arriba son honestos y no cómodos. No son bajos porque se hayan quitado funciones y empujado a otro proceso para esconderlas. Son bajos porque las partes que necesitan mucha memoria son las que tienen permiso para tener la suya.

Dónde muerde este diseño

La tercera fila de esa tabla no era una errata. Abre un único archivo de texto de 6,3 MB, unas ciento veintinueve mil líneas, y MeatPad supera el gigabyte y satura un núcleo.

La causa no es el motor de texto, que se comporta exactamente como se anuncia. Es la barra de estado. Muestra líneas, palabras y caracteres del documento, y calcula las tres recorriendo todo el texto cada vez que la interfaz se vuelve a maquetar. En una nota o en un archivo fuente eso son unos pocos kilobytes y nadie lo nota. En ciento veintinueve mil líneas convierte cada pasada de maquetación en un recorrido completo de seis megabytes de texto, y la interfaz se maqueta muchísimo.

El arreglo es pequeño, los recuentos deben calcularse una vez cuando cambia el texto y no una vez por dibujado, y está en la cola. Lo escribimos aquí en lugar de omitirlo porque un artículo sobre memoria que solo enumera las buenas mediciones es un anuncio. Los archivos de cada día, los que de verdad se abren en un editor, caben en las dos primeras filas. Los archivos únicos muy grandes son la frontera, y nos toca a nosotros arreglarla.

Por qué esto merece una tarde

La mayoría de los Mac que se venden tienen 16 GB de memoria, y casi nadie tiene un gigabyte de sobra: el navegador lleva treinta pestañas, la herramienta de diseño está abierta, algo está compilando. La memoria que retiene un editor es memoria que el compilador no puede usar, y cuando se acaba, macOS empieza a comprimir y a usar el disco, lo que se percibe como que todo empeora un poco a la vez.

Una app nativa que toma prestados los frameworks del sistema, maqueta solo lo visible, mantiene tus documentos como archivos y deja que los servidores de lenguaje corran en sus propios procesos acaba en unos 63 MB sin que nadie haya optimizado nada. No es una historia heroica de ingeniería. Es el resultado normal de no haber empezado construyendo un navegador.