¿Volveremos a optimizar? La crisis de la RAM y el software

Q: ¿Qué era la configuración múltiple de MS-DOS?

Un menú de arranque que llegó con MS-DOS 6, en 1993. En CONFIG.SYS se definían varias configuraciones y, al encender el ordenador, elegías una según lo que fueras a usar. Así podías arrancar con pocos controladores y dejar libre la mayor cantidad posible de memoria convencional para un juego.

Aprendí a programar en ordenadores que no llegaban ni a medio mega de memoria RAM. Allí, optimizar no era una opción: era la única forma de que algo arrancase.

Y ahora la RAM se ha vuelto a poner por las nubes. Escasea, sube de precio y, según las previsiones, seguirá así un buen rato. Así que me hago una pregunta: si la memoria vuelve a ser un recurso caro, ¿volveremos a optimizar como se optimizaba antes?

Para contestarla hay que recordar cómo era aquello, qué pasó después y qué está pasando ahora. Vayamos por partes.

Cuando optimizar era arrancar el PC de otra manera

En el PC de los noventa, el sistema operativo trabajaba con una memoria convencional limitada a 640 KB. Todo lo que querías cargar tenía que caber ahí o buscarte la vida con memoria extendida o expandida. Para jugar a un juego tenías que optimizar tú, como usuario: tocando los archivos de arranque (CONFIG.SYS y AUTOEXEC.BAT) y ajustando a mano la memoria para que cupiera. Si no lo hacías, el juego no cargaba. PUNTO.

La solución que acabó imponiéndose fue la configuración múltiple, un menú de arranque que llegó con MS-DOS 6, en 1993. En lugar de tener un único arranque para todo, preparabas varios y elegías al encender el ordenador cuál querías, según lo que fueras a ejecutar: uno con todos los controladores para trabajar, otro pelado para el juego que pedía hasta el último kilobyte libre.

Funcionaba así. En CONFIG.SYS declarabas un bloque [menu] con las opciones, una de ellas por defecto con un tiempo de espera, y un bloque por cada configuración. En AUTOEXEC.BAT, MS-DOS te dejaba el nombre de la elegida en una variable, %CONFIG%, y con un GOTO saltabas a la parte que tocaba. Un ejemplo ilustrativo, escrito de memoria:

[menu]
menuitem=TRABAJO, Windows y programas
menuitem=JUEGO, Juego que pide mucha memoria
menudefault=TRABAJO, 5

[common]
device=C:\DOS\HIMEM.SYS
dos=high,umb

[TRABAJO]
device=C:\DOS\EMM386.EXE

[JUEGO]
rem Solo lo imprescindible

@ECHO OFF
GOTO %CONFIG%

:TRABAJO
REM Aquí cargaba los controladores del día a día
GOTO FIN

:JUEGO
REM Aquí, casi nada
GOTO FIN

:FIN

La revista Compute! lo explicaba en 1993. El esquema con un bloque común y uno por opción es el que explica también Dave Farquhar. Era un trabajo artesanal y molesto, y aun así aprendías sin querer cómo funcionaba el ordenador por dentro.

Y el que programaba también optimizaba

No era cosa solo del usuario con el arranque. El software en general se optimizaba mucho más, y eso se notaba al programar.

Cuando yo aprendí a programar, en esa época, no era muy avanzado. Pero ya se hablaba de medir mucho qué variables usabas y de utilizar las justas, porque no podías tener infinitas: ocupaban espacio. Lo sensato era reutilizarlas y vaciarlas cuando ya no las necesitabas. Una idea sencilla, que hoy suena a manía de abuelo, y que te obligaba a saber en cada momento cuánto estabas gastando.

Un ejemplo ilustrativo de la idea, no un consejo para hoy:

// Una variable nueva por cada paso: tres espacios ocupados
let suma1 = a + b;
let suma2 = suma1 + c;
let total = suma2 + d;

// Reutilizando una sola: un espacio
let total = a + b;
total = total + c;
total = total + d;

Como programador era peor y mejor a la vez: peor porque no había margen, mejor porque no había nada que no pudieras entender entero.

Cuándo dejamos de optimizar

En algún momento, entre mediados de los noventa y el 2000, los ordenadores se volvieron tan potentes que dejó de importar. Memoria de sobra, procesadores de sobra, y la mentalidad cambió: ya no hacía falta ser cuidadoso, el hardware aguantaba. “Si va lento, compra más RAM.”

Y esa costumbre se quedó con nosotros. Cada generación de hardware se comió la mejora de la anterior con software más pesado. Y ahora hemos llegado al extremo: ni siquiera se programa. Lo hace una Inteligencia Artificial, sin tener en cuenta recursos ni nada.

¿Volveremos a optimizar? La crisis de la RAM

Aquí está la gracia. Esa frase, “compra más RAM”, llevaba décadas saliendo gratis, y ya no.

La causa, según varios análisis, es la demanda de memoria para los centros de datos de Inteligencia Artificial, que se come capacidad de fábrica que antes era memoria de PC y móvil. En cuanto a los precios, el análisis de Jefferies que recogía Xataka preveía que un módulo de 16 GB de DDR4 pasase de 139 euros a ±209 en el tercer trimestre y a ±292 en el cuarto, y que en 2027 las subidas anuales siguieran entre el 40 y el 45 %. Ojo, son previsiones, y las cifras varían mucho de un medio a otro. Lo que sí coincide en todas es la dirección.

Y hay un síntoma que me parece el más interesante. Según Windows Latest, el responsable de Windows, Pavan Davuluri, ha admitido que el coste creciente de la memoria empuja a Microsoft a hacer que Windows 11 use menos RAM. Trabajan en el gestor de memoria, en la compresión, en WinUI 3 y en WebView2, y desde el 31 de julio “optimización de memoria para 8 GB o más” figura como prioridad oficial para 2026. Es lo que cuenta también OSNews.

Fíjate en lo que pasa: la empresa que lleva décadas apoyándose en que el hardware aguante vuelve a mirar cuánta memoria gasta. No porque haya descubierto la virtud, sino porque ahora le cuesta dinero.

Lo que me pregunto

Me pregunto si esto bastará para que se vuelva a optimizar como antes. La historia apunta en esa dirección: cuando la memoria falta, se optimiza, y cuando sobra, se deja de hacer.

Pero hay otro camino igual de posible: que el sobrepeso no se arregle y acabe pagándolo el cliente, con equipos más caros. Es la opinión que se lee en muchos foros de desarrolladores, así que la cuento como lo que es, una opinión. Y encima ahora hay una máquina escribiendo código sin preocuparse de cuánto gasta.

El último ejemplo: el nuevo launcher de Epic

Estaba leyendo la noticia del nuevo launcher de Epic Games cuando me saltó el resorte. Según cuenta Vandal, Epic ha reconstruido la aplicación desde cero porque la lentitud del antiguo era una de las quejas más repetidas durante años. Dos datos que me llamaron la atención:

Epic presume de que la biblioteca carga 30 veces más rápido que en la versión anterior. Treinta veces. Eso no es una mejora, es admitir lo mal que iba antes.
La propia compañía reconoce que lo ha desarrollado con herramientas de Inteligencia Artificial, lo que ellos llaman vibe coding.

También dan cifras frente a Steam (arranque en 5,47 segundos contra 10,07), aunque son pruebas encargadas por Epic y avisan de que depende del equipo. Para ser justos con ellos: está en preview y con pocas funciones, y rehacer algo desde cero y que mejore es lo que toca.

Lo que me parece revelador no es el launcher, es que hiciera falta rehacerlo entero para que dejase de ir lento, y que el método que estrenan para eso sea escribirlo sin escribirlo. Es el ejemplo perfecto de la pregunta de antes: la optimización llega cuando el problema duele, no antes.

Qué podemos hacer

Como desarrollador, nada que no supieras: medir antes de dar nada por bueno, mirar el consumo de memoria como mira un mecánico el cuentakilómetros, y no aceptar el código de una Inteligencia Artificial sin entender qué hace con los recursos.

Un hábito que te recomiendo si programas: elige una aplicación tuya cada trimestre y mídela en reposo, con el monitor de recursos del sistema o el perfilador de tu lenguaje. Seguramente te lleves una sorpresa. Y apunta la cifra, porque lo que no se mide se degrada sin que nadie lo vea.

Como usuario, algo igual de simple: quejarte con datos. Un “va lento” se ignora; un “esta aplicación gasta tantos megas en reposo” se arregla.

Y si tienes una aplicación de tu negocio que va lenta o pesa demasiado, cuéntame el caso y vemos si es cuestión de optimizar o de rehacer.

Precios consultados el 19 de octubre de 2026.

Fuentes

Preguntas frecuentes

¿Volverá la optimización del software por la crisis de la RAM?

Es posible, y ya hay un primer síntoma: Microsoft ha puesto la optimización de memoria de Windows 11 como prioridad oficial para 2026 por el coste creciente de la RAM. Pero también puede ocurrir que el sobrepeso del software se traslade al usuario en forma de equipos más caros. Hoy no hay forma de saberlo.

¿Qué era la configuración múltiple de MS-DOS?

Un menú de arranque que llegó con MS-DOS 6, en 1993. En CONFIG.SYS se definían varias configuraciones y, al encender el ordenador, elegías una según lo que fueras a usar. Así podías arrancar con pocos controladores y dejar libre la mayor cantidad posible de memoria convencional para un juego.

¿Por qué antes se optimizaba más?

Porque el hardware lo exigía: con menos de medio mega de RAM, un programa sin optimizar simplemente no cabía. Cuando la potencia dejó de ser un límite, el incentivo desapareció.

¿Qué es el vibe coding?

Programar describiéndole a una Inteligencia Artificial lo que quieres y aceptando lo que genera, sin revisar o entender necesariamente cada línea. Epic Games ha reconocido que ha usado esta metodología en su nuevo launcher.

Compártelo si te ha resultado útil.

¿Qué truco de los noventa para ahorrar memoria recuerdas tú? Cuéntame.

Y… a ver si la crisis de la RAM nos devuelve las ganas de optimizar.