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

Subject: Re: [Boost-users] [serialization] speed & size optimized binaryarchive
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-11-19 11:47:51

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