Optimización del diseño de la memoria de las instancias de clase en C++

Question

La actualización de una aplicación de 32 a 64 bits aumenta el tamaño del puntero y la huella de memoria de los objetos.

Estoy buscando métodos para reducir la huella de memoria de los objetos tanto como sea posible. Para las estructuras de POD, elimino el diseño de memoria de la estructura para ver cómo empacar los miembros y reducir el relleno del compilador.

¿Hay una manera de entender el diseño de memoria de la no-POD objetos como instancias de clases? ¿Cómo podría lograr algo similar al empaque de objetos de clase?

Gracias, Dan

Answer 1

No sé sobre específicos no POD objetos de datos (es decir vtable), aunque supongo que es dictado por el tamaño del puntero. De todos modos, se puede controlar la alineación de los miembros de la directiva del compilador #pragma pack que es apoyada tanto por GCC y Visual Studio.

También puede leer el párrafo 7.18 en la maravillosa Agner Fog C++ optimize guide:

Los miembros de datos de una clase o estructura se almacenan consecutivamente en el orden en el que se declaran cada vez que se crea una instancia de la clase o estructura . No hay una penalización de rendimiento de por organizar datos en clases o estructuras. El acceso a un miembro de datos de una clase u objeto de estructura no requiere más tiempo que el acceso a una variable simple. mayoría de los compiladores se alinearán los miembros de datos a direcciones redondas con el fin de optimizar el acceso

Answer 2

Puede usar GCC -Wpadded de informarle que se añade el relleno, a continuación, volver a ordenar en base a esa información, la reducción del tamaño en algunos casos.

Force-Packing los datos no son una buena idea para las representaciones en la memoria.

Answer 3

Regla de oro: mayor a menor; esto proporciona una alineación perfecta cuando los tamaños de los elementos son potencias de dos, de lo contrario, son posibles las optimizaciones manuales.

Tenga en cuenta que la alineación adecuada suele ser esencial para la velocidad, incluso si la CPU se recupera de violaciónes. Mientras que la CPU x86 y (AFAIK) x64 desalinean el acceso internamente con una segunda lectura, el tiempo "perdido" en una lectura de desalineación suele ser mucho mayor que el tiempo ahorrado debido a un conjunto de trabajo más pequeño. Así que "empacaré apretadamente" solo cuando ejecute comparaciones en múltiples CPU.

Para los no-POD de que tendría que comprobar los sizeof(element) 's.
(Si hay un montón de objetos, probablemente me vaya con un simple analizador generar el C++ para volcar estos tamaños)

Alternativamente, PVS-Studio tiene un análisis de tamaños struct y da sugerencias de reordenamiento. Todavía no los he considerado demasiado, pero podrías usar la evaluación para ver si funciona para ti.

Answer 4

relativa a los objetos no-POD, creo que usted debe leer más sobre vtable, función virtual, la herencia virtual para saber qué cosas llevar a cabo el tamaño de la clase u objeto.De hecho, la alineación de clase que sigue el relleno, la alineación de miembros de clase solo uno de los factores conduce el tamaño de la clase.

Aquí hay algunos sitios web relacionados, creo que pueden ser útiles para usted.

1. Determinar el tamaño del objeto de clase: diseño http://www.cprogramming.com/tutorial/size_of_class_object.html

2. memoria: http://www.phpcompiler.org/articles/virtualinheritance.html

Y, si utiliza MVSC, se puede volcar todo el diseño de memoria de toda clase en su solución con -d1reportAllClassLayout así:

cl -d1reportAllClassLayout main.cpp