2010-12-29 30 views
7


del mismo modo que el tema sugiere que he encontrado un pequeño problema con boost :: serialización al serializar una gran cantidad de datos en un archivo. El problema consiste en que la huella de memoria de la parte de serialización de la aplicación toma entre 3 y 3,5 veces la memoria de mis objetos que se serializan.
Es importante tener en cuenta que la estructura de datos que tengo es un vector tridimensional de punteros de clase base y un puntero a esa estructura. De esta manera:boost :: serialización alto consumo de memoria durante la serialización

using namespace std;  
vector<vector<vector<MyBase*> > >* data; 

Esta es posterior serializado con un análogo de código a la siguiente:

ar & BOOST_SERIALIZATION_NVP(data); 

realce/serialización/vector.hpp está incluido.

Todas las clases que se serializan heredan de "MyBase".
Ahora, desde el comienzo de mi proyecto he utilizado diferentes archivos para la serialización de binary_archive, text, xml y finalmente bmmorphic binary/xml/text. Cada uno de estos actos exactamente de la misma manera.

Normalmente, esto no sería un problema si tuviera que serializar pequeñas cantidades de datos, pero el número de clases que tengo son de millones (idealmente alrededor de 10 millones) y el uso de memoria ya que he podido probarlo muestra consistentemente que la memoria asignada por boost :: serialization parte del código es alrededor de 2/3 de la huella de la memoria completa de la aplicación al escribir el archivo.

Esto equivale a alrededor de 13.5 GB de RAM tomados para objetos de 4 millones donde los objetos mismos toman 4.2GB. Ahora, esto es lo más lejos que he podido tomar mi código, ya que no tengo acceso a una máquina con más de 8 GB de RAM física. También debería tener en cuenta que esta es una aplicación de 64 bits que se ejecuta en una edición x64 profesional de Windows 7, pero la situación es similar en una caja de Ubuntu.

Alguien tiene alguna idea de cómo voy a solucionar este problema, ya que es inaceptable para mí tener requisitos de memoria tan altos para una aplicación que no utilizará tanta memoria mientras se ejecuta como durante la serialización.

La deserialización no es tan mala, ya que asigna alrededor de 1,5 veces la memoria necesaria. Esto es algo con lo que podría vivir.

Intentó desactivar el seguimiento con boost :: archive :: archive_flags :: no_tracking pero funciona exactamente igual.

¿Alguien tiene alguna idea de lo que debo hacer?

+0

Acaba de registrarse para toparse con el tema ya que nadie respondió aún ... – Max021

+0

Tema interesante. Lea esto: http: // stackoverflow.com/questions/1058051/boost-serialization-performance-text-vs-binary-format –

+0

La bandera 'no_tracking' lamentablemente no está implementada (hay alguna discusión sobre el rastreador de problemas al respecto)./cc @MohsenTamiz – sehe

Respuesta

1

Usando valgrind encontré que la razón principal del consumo de memoria es un mapa dentro de la biblioteca para rastrear punteros. Si está seguro de que no necesita el seguimiento del puntero (significa que está seguro de que no hay alias del puntero), deshabilite el seguimiento. Puede encontrar here los conceptos principales de deshabilitar el seguimiento. En resumen hay que hacer algo como esto:

BOOST_CLASS_TRACKING(vector<vector<vector<MyBase*> > >, boost::serialization::track_never) 

en my question me escribió una versión de esta macro que se puede deshabilitar el seguimiento de una clase de plantilla. Esto debe tener un impacto significativo en su consumo de memoria. Observe también que hay punteros dentro de los contenedores. Si desea realizar un seguimiento nunca debe deshabilitar el seguimiento de ellos también. Actualmente no pude encontrar ninguna manera de hacer esto correctamente.

+0

A menos que necesite el seguimiento, por supuesto. (Puede guardar más memoria deshabilitando la serialización). La solución real aquí sería no usar la serialización de punteros – sehe

+0

Upvoted para la macro "agradable" para clases de plantilla (bueno, es una macro, siempre he usado la especialización parcial hasta ahora) – sehe

Cuestiones relacionadas