[Boost-users] [Serialization] binary archive 1.75 times larger than source data

From: Sebastian.Karlsson_at_[hidden]
Date: 2008-09-03 03:39:57

Hi,

So I've got most of my serialization working now, the only problem now  
is that it's still largely inefficent. The resulting binary file is  
1.75 times larger than the sourcer XML file which I parse from.

This is probably a lot due to the fact that I still default tracking  
and version everything. What I'd love to do however is to specify on a  
archive by archive basis if I want tracking / versioning. In fact,  
isn't this what one would normally want to do? When you specify  
tracking on a class by class basis you have no idea if there will be  
multiple pointer to the same object of that type. I found the  
no_tracking which I found a reference to from 2006 on this very  
mailing list, however it still doesn't seem to affect at least archive  
size ( haven't checked deserialization timings for it ).

When I take a look at the deserialization the binary archive seems to  
store identifiers for types as their straight up string versions. This  
also seems largely inefficient, is there a reason for why this can't  
just be a hash?

Also, is binary archives streaming or do they wait until the entire  
archive is loaded?

Basically I'm wondering what would be the fastest possible archive one  
could create if one doesn't care about portability.

// Sebastian Karlsson