Por qué un editor de texto de hace 40 años machaca al "todopoderoso" Atom

Me van a caer críticas por doquier, pero aquí tenéis a un fan absoluto de emacs. Nunca pude con vi, pero eso al final da igual: cualquiera de los dos es un ejemplo de eficiencia y versatilidad, y parece absurdo hasta dónde hemos llegado en el segmento de los editores de texto.

De hecho un reciente análisis del comportamiento de estos editores demuestra que vi, un editor creado hace más de 40 años, es mucho más eficiente que el todopoderoso Atom, uno de los editores de texto más populares entre usuarios y desarrolladores. Es bonito y potente, cierto, pero tiene un problema: su glotonería de recursos es preocupante.

Lucha de editores de texto

Hay toda una subcultura en el segmento de los editores de texto, y esa afición nuestra de discutir por todo y todos ha convertido a esta en una de las batallas software más encarnizadas de la historia.

Ya no es solo vi vs emacs, ahora es vi & emacs contra todos los demás, porque estos editores creados en los (¿buenos y?) viejos tiempos siguen mostrando cómo funcionaba antes la informática y como lo hace ahora.

Un desarrollador lo demostraba con Vim ("Vi improved"), la versión mejorada de este editor que apareció por primera vez en 1991 para mi adorado Commodore Amiga —fui usuario y defensor a ultranza de dichas máquinas durante casi una década—. Vim es un gran editor, pero su validez o popularidad se ha ido degradando ante la aparición de editores de texto cada vez más llamativos y más atractivos.

Las pruebas lo demuestran: vim es mucho más eficiente

Sublime Text, Code o el célebre Atom se han convertido en los nuevos referentes de los desarrolladores de las nuevas generaciones, pero un análisis de algo tan simple como su uso de recursos demuestra que estas aplicaciones modernas son de todo menos eficientes. Al comparar cuánta memoria necesitaban para abrir un simple programa en C de 60 bytes la respuesta era asombrosa:

(Visual Studio) Code necesita 349 Mbytes de memoria para abrir ese fichero, por los 256 Mbytes de Atom. Vim necesita 5 Mbytes, que no es tampoco poca cosa, mientras que GNU nano, otro de los editores clásicos de entornos Linux, usaba algo menos de 1 Mbyte.

Este desarrollador repetía la prueba con un fichero mucho mayor: un XML de 6 Mbytes, y de nuevo los editores modernos mostraban cómo se las gastan. O más bien, cómo gastan memoria, porque Atom necesitaba la friolera de 845 Mbytes de memoria para abrirlo por 392 de Code o los 12 Mbytes de Vim. En ambos casos Sublime Text se comportaba de forma bastante más comedida.

En esa misma comparación se evaluó el tiempo necesario para abrir el fichero y mover el cursos hasta el final de ese XML gigante. Sublime Text fue casi el más rápido (bien por este desarrollo), mientras que Atom y Code tardaron 20 segundos en dejarnos empezar a hacer algo.

Al hacer una búsqueda y sustitución de una palabra que se repetía 100.000 veces en ese fichero, más de lo mismo: Atom se colgó varias veces, Code tardó 80 segundos, Sublime 6 y Vim solo 4. La sorpresa negativa fue para nano, que tardó 10 minutos en acabar con la tarea.

La culpa la tiene Electron

¿Cuál es la razón de esa falta de eficiencia de Code o de Atom? Una muy sencilla: mientras que Sublime Text está desarrollado de forma nativa, tanto Atom como Microsoft Visual Studio Code se basan en el uso de Electron, una plataforma que hace uso de Node.js para el backend y del navegador Chromium para el frontend.

Aunque la plataforma ofrece una potente infraestructura para que ciertos clientes y aplicaciones tengan una interfaz y unas opciones muy interesantes, también impone unos requisitos enormes a la hora de funcionar. Es cierto que la situación puede haber mejorado un poco tras el salto a Electron 2.0, más rápido y estable, pero aún así ese consumo de recursos sigue siendo demasiado elevado.

No solo Atom o Visual Studio Code utilizan Electron, y hay otros casos famosos como los de Slack o Spotify que han sido criticados por el enorme consumo de recursos que tienen. Bien por las opciones, desde luego, pero si queréis eficiencia en vuestro editor de texto, ya sabéis: nada como vim... o emacs, que seguramente hubiera obtenido resultados similares a este último.

En Xataka | Así es usar la consola Bash de Ubuntu en Windows 10