2010-08-08 16 views
5

He leído sobre Asignación de objetos pequeños en "Diseño moderno en C++". Andrei Alexandrescu argumenta que los operadores de propósito general (nuevo y eliminar) funcionan mal para asignar objetos pequeños.¿Qué se considera un objeto pequeño en C++?

En mi programa hay muchos objetos creados y destruidos en la tienda gratuita. Estos objetos miden más de 8000 bytes.

¿Qué tamaño se considera pequeño? ¿Son 8000 bytes pequeños o grandes cuando se trata de asignación de memoria en C++?

+0

Depende de la implementación. – kennytm

+2

¿Los objetos miden individualmente 8000 bytes o acumulativamente? Mientras @KennyTM dijo que depende de la implementación, a 8000 bytes por objeto no hay muchas implementaciones del mundo real donde ese objeto se considere pequeño –

+0

@Jared P, cada objeto mide más de 8000 bytes. Mi programa debería ejecutarse de manera muy eficiente en los sistemas de servidor de Windows y Linux. –

Respuesta

13

La definición de "pequeño" varía, pero en general, un objeto puede considerarse "pequeño" si su tamaño es menor que el tamaño de sobrecarga causado por la asignación del montón (o es al menos cercano a ese tamaño).

Por lo tanto, un objeto de 16 bytes probablemente se consideraría "pequeño" en la mayoría de los casos. Un objeto de 32 bytes puede considerarse pequeño en determinadas circunstancias específicas. Un objeto de 8,000 bytes definitivamente no es "pequeño".

Por lo general, si va a tomarse la molestia de usar un pequeño asignador de objetos, está buscando mejorar el rendimiento de algún bloque de código. Si usar un pequeño asignador de objetos no ayuda a su rendimiento, probablemente no debería usar uno.

1

Ciertamente no consideraría 8000 bytes como 'pequeños'. Los objetos pequeños probablemente significan objetos que ocupan no más de unos pocos cientos de bytes; objetos que equivalen a un puñado de bytes generarán los mayores problemas, sin embargo, como KennyTM señala, esto depende de la implementación y algunos tiempos de ejecución de C++ pueden ser excelentes para el manejo objetos pequeños

3

[...] argumenta que los operadores de propósito general (nuevo y eliminar) funcionan mal para asignar objetos pequeños.

Depende de la plataforma. P.ej. en Linux una vez evalué mi árbol AVL de cosecha propia con gestión de memoria estática frente a std :: map de GNU, que es un árbol rojo-negro y una gestión de memoria totalmente dinámica. Para mi sorpresa, std :: map a veces superó mi propia implementación altamente eficiente. Y std :: map hace una cantidad peligrosa de pequeñas asignaciones de memoria.

En mi programa hay muchos objetos creados y destruidos en la tienda gratuita.

La preocupación por la administración de la memoria es válida. En cierto sentido, siempre debe intentar reutilizar los recursos existentes si es posible o evitar la creación de copias temporales.

Eso es si la eficiencia/rendimiento de la CPU que busca. Si el código se ejecuta raramente, entonces no tiene sentido molestarse.

Estos objetos miden más de 8000 bytes. ¿Qué tamaño se considera pequeño? ¿Son 8000 bytes pequeños o grandes cuando se trata de asignación de memoria en C++?

Esta es una pregunta sin sentido. Si su programa necesita un objeto que tome 8K, entonces su programa lo necesita. Período.

Debería comenzar a preocuparse solo si recibe quejas de que el software requiere demasiada RAM o el perfilador apunta al cuello de botella de rendimiento en la gestión de la memoria. De lo contrario, la gestión de memoria moderna es relativamente rápida y robusta.

P.S. Personalmente, consideraría 8K como un tamaño promedio de asignación de memoria. No es pequeño, no es grande. Pero ya estoy acostumbrado a trabajar con programas que, por capricho, asignan 10 + GB en montón. Si el conjunto de datos debe residir en la RAM y tiene un tamaño de 10 GB, entonces la aplicación no tiene más remedio que intentar cargarlo.

0

La pregunta no es, ¿qué tan pequeño es el objeto, pero, cuánta sobrecarga de memoria es invocada por el operador new/delete? Si su objeto es más que eso, entonces no es tan pequeño.

Cuestiones relacionadas