¿Pueden los programadores reducir la cantidad de RAM que usan algunas aplicaciones?

Existe una compensación enorme en tiempo de desarrollo versus optimización de ejecución.

Habiendo escrito cosas que tenían que ejecutarse en una memoria muy, muy limitada, hay un montón de trucos que puedes poner en práctica, a menudo usando la reimaginación creativa de los problemas como sugiere Greg Kemnitz, y siempre con un espacio contra el tiempo compensación.

Lo cierto es que el advenimiento de la memoria virtual eliminó cualquier incentivo que la mayoría de los programadores tenían que preocuparse por ese tipo de cosas. Simplemente trabaja dentro de los límites de su espacio de direcciones (32 o 64 bits) y deja que el sistema operativo resuelva cómo funciona todo en cuantos de tamaño de página.

Agregue eso a la ley de Moore, donde tiene memoria y CPU más baratas y rápidas de forma regular, y simplemente no puede entusiasmar a nadie por preocuparse por escribir código realmente eficiente. Simplemente no vale la pena para ellos. Saben que es lento, pero mejorará pronto, ya que funcionará con 8 GB de memoria estándar con un SSD de 500 GB, en lugar de 2 GB con un disco duro de 5400 RPM. Y si todavía estás ejecutando esa vieja mierda decrépita, hombre, ¡obtén una actualización!

Me enfrento a esto todo el tiempo. Mis desarrolladores tienen CPUs de cuatro núcleos, toneladas de RAM y SSD, con GPU de alta potencia. Increíble. (En realidad, es impresionante y hace una diferencia de productividad medible).

El problema es…. nuestro usuario promedio está en una CPU dual-core mucho más antigua y lenta con quizás 4 GB de RAM y HDD de grado de consumo. Mantengo un par de sistemas así solo para ver cómo funciona el código. E inevitablemente, cuando el software se ejecuta como basura, tengo que molestar a las personas para que ejecuten los perfiladores, comenzar a pensar en cuánta memoria están usando, etc.

Lo que estás viendo, particularmente en Chrome, es la falta de ese último paso. La configuración del desarrollador en Google es más que increíble, pero hay una notable falta de pensamiento sobre cuál será la experiencia del usuario final en hardware menos capaz.

Hay muchas compensaciones en el diseño de un algoritmo o una aplicación con respecto al uso de RAM. Aquí hay uno simple: cuente cuántos bits se establecen en una secuencia dada de bytes.

Podría hacerlo con un simple bucle sobre los bits, lo que tomaría poca RAM pero tomaría tiempo O (nbits).

Podría usar una matriz de búsqueda para hacer su recuento byte por byte, con la matriz parecida a

uint8 byte_bits_count[256] = {0, 1, 1, 2, 1, 2, 2, 3, ..., 7, 8};

y haga una búsqueda por byte, que sería 8 veces más rápido que el primer enfoque, a costa de usar 256 bytes de RAM.

O podría usar un enfoque híbrido donde verifique la mitad de los bits en cada byte en cada iteración y use una matriz de búsqueda de 16 bytes que sea similar a la anterior. Sería 4 veces más rápido que la primera opción y usaría 1/16 de la cantidad de RAM como la segunda, mientras que es el doble de lento.

(Sí, también podría usar una declaración de cambio con valores en lugar de una matriz de búsqueda, pero es básicamente lo mismo en términos de uso real de RAM).

La elección que usaría dependería de los requisitos de su aplicación en este bit de código. Si está en un dispositivo pequeño, puede elegir la opción 1 o posiblemente la opción 3 para reducir el uso de RAM. Si está en una computadora de “tamaño completo”, puede optar por la opción 2 como “RAM es barata”.

Una aplicación interesante tiene todo tipo de compensaciones, y en general Chrome ha elegido favorecer el rendimiento sobre la eficiencia de RAM.

Sí, pero en muchos casos serán más lentos. En el ejemplo de Google Chrome, el programador podría optar por almacenar datos en el disco, que es mucho más lento. O bien, recuperar datos de la red.

Para otras aplicaciones que hacen uso de la computación, el programador podría elegir recalcular la información que necesita en lugar de almacenarla en la RAM.