Cada vez que tenga una aplicación que tenga una ruta crítica intensiva en rendimiento, debe preocuparse cómo trata la memoria. La mayoría de las aplicaciones del lado del cliente del usuario final no entran en esta categoría porque son impulsadas por eventos primarios y la mayoría de los eventos provienen de interacciones con el usuario, y eso no tiene tantas restricciones de rendimiento (si es que tiene alguna).
Sin embargo, una gran cantidad de software de back-end debería centrarse en cómo se maneja la memoria porque gran parte de ese software puede ampliarse para manejar un mayor número de clientes, un mayor número de transacciones, más fuentes de datos ... Una vez que comience Al superar los límites, puede comenzar a analizar cómo la memoria de los usuarios de su software y escribir esquemas de asignación personalizados adaptados a su software en lugar de confiar en un asignador de memoria completamente genérico que fue escrito para manejar cualquier caso de uso imaginable.
Para darle algunos ejemplos ... en mi primera empresa trabajé en un paquete Historian, software responsable de recopilar / almacenar / archivar datos de control de procesos (piense en una fábrica, planta de energía nuclear o refinería de petróleo con 10 de millones de sensores, almacenaríamos esos datos). Cada vez que analizamos cualquier cuello de botella de rendimiento que impedía al Historian procesar más datos, la mayoría de las veces el problema estaba en cómo se manejaba la memoria. Hemos hecho grandes esfuerzos para asegurarnos de que no se llamara a malloc / free a menos que fuera absolutamente necesario.
En mi trabajo actual, trabajo en la grabadora digital de video de vigilancia y el paquete de análisis. A 30 fps, cada canal recibe un cuadro de video cada 33 milisegundos. En el hardware que vendemos, podemos grabar fácilmente 100 canales de video. Así que ese es otro caso para asegurarse de que en la ruta crítica (llamada de red => componentes de captura => software de gestión de grabadora => componentes de almacenamiento => disco) no haya asignaciones de memoria dinámica. Tenemos un asignador de trama personalizado, que contiene cubos de búferes de tamaño fijo y utiliza LIFO para reutilizar los búferes previamente asignados. Si necesita 600Kb de almacenamiento, puede terminar con un buffer de 1024Kb, lo que desperdicia espacio, pero debido a que está diseñado específicamente para nuestro uso donde cada asignación es muy efímera, funciona muy bien porque se usa el buffer,
En el tipo de aplicaciones que describí (mover muchos datos de A a B y manejar grandes cantidades de solicitudes de clientes) ir al montón y viceversa es una fuente importante de cuellos de botella en el rendimiento de la CPU. Mantener la fragmentación del montón al mínimo es un beneficio secundario, sin embargo, por lo que puedo decir, la mayoría de los sistemas operativos modernos ya implementan montones de baja fragmentación (como mínimo, sé que Windows lo hace, y espero que otros también lo hagan). Personalmente, en más de 12 años trabajando en este tipo de entornos, he visto problemas de uso de CPU relacionados con el montón con bastante frecuencia, mientras que nunca he visto un sistema que realmente sufriera un montón fragmentado.