Sebastian Karlsson wrote:
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.
The class name is used only for exported types which are serialized through base class pointers. each class name is looked up only one time during the loading of an archive so I would expect that the impact on the execution would be undetectable. The class name is used only once per archive. If your application is so fast and your archives are so small that these factors make an impact you could chose short text names perhaps generated by your own method which would make them very short - maybe 2 characters long. Of course if you can just avoid all of the above by avoiding the serialization of pointers through a base class which is the only place where the look up class names is used. In other words - don't use BOOST_CLASS_EXPORT. If you application is so time critical thay the time for storing /loading the class name is detectable, I would guess you're not using this facility as the redirection through virtual base class is in fact a measurable time impact that occurs on every read/write - not just once per archive.
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 serialization library separates the saving/loading of data types in an "archive" implementation. Any conforming archive implementation can be used once the serialization for all data types is defined. The library includes a number of archive implementations for different purposes. Some ar as fast as they can be - binary archives while others address other requirements - e.g. xml compatibility. These can be used as examples along with the documentation, demos and tests to create a new archive implementation should a user find that the included implementation fails to meet one or more of his requirements. The test suite is parameterized by archive implementation so that if a user were to make his own archive (as some have - see MPI library), the current tests can be used to verify that the new archve can handle all the serialization facilities.
This I would find rather sad, especially since this is areas where the language is often used.
If you're really interested in this subject, I think you would find that spending some more time reading the documentation and demos would be productive. Robert Ramey