Re: [Boost-users] [serialization] speed & size optimized binary archive

Subject: Re: [Boost-users] [serialization] speed & size optimized binary archive
From: Sebastian Karlsson (sebastian_at_[hidden])
Date: 2009-11-19 08:15:46

Turns out I needed to handle serialization of strings explicitly,
which fixed the error.

Looking at how class_name_type is handled throughout the source it
seems its type is set in stone, furthermore it seems I pay at least an
additional 128 bytes per exported class type, I guess this is
convenient when serializing in text format for easy viewing, but for
use cases where memory is at a premium and a hash would suffice it
would be nice if this type was configurable throughout the system. I'm
guessing this string is used in the extended_type_info system
mentioned in the manual, leading me to believe that the lookup table
for exported types uses a costly string compare to find the correct
derived type.

Neither performance, memory use or archive size is mentioned as a
specific consideration in the manual amongst the 11 goals, leading me
to believe perhaps the library simply isn't suited for domains where
these are of importance? This I would find rather sad, especially
since this is areas where the language is often used.