Boost logo

Boost :

Subject: Re: [boost] Comparison of serialization results
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-12-29 15:50:35

on Thu Dec 29 2011, Brian Wood <> wrote:

> I found an error that affects two of my test cases -- not comparing
> apples to apples -- so have updated the page I linked to and the
> archive with the tests. Only one of the tests showed different results
> after the change. Rather than claiming the Boost Serialization
> version of the test was over 3 times slower than the Ebenezer
> version, I now claim it is over 2.3 times slower.
> Dave Abrahams:
>> A few:
>> 1. The claim that you provide "full generation of marshalling functions"
>> is a little hard to swallow. In principle, it's impossible to know
>> based on a class declaration what to serialize, and how to serialize
>> it.
> True. In order to turn off the default generation of marshalling
> code, one can place a comment like this:
> // hand_written_marshalling_code
> in the body of a class. Instances of that class can still be
> marshalled if you provide the expected marshalling functions yourself.

No post-hock marshalling? You should be able to add marshalling to a
class without modifying its declaration.

>> 2. If you are going to compare yourself to Boost.Serialization, it would
>> be a good idea to replicate all of that library's tests with your own
>> system, to demonstrate that you cover the same expressive range.
> We don't cover the same range, but are working to add to the
> reperoire.

Then you should demonstrate which things you do cover.

> We do have support for some things that the
> Boost library doesn't: iterator_range, sub_range, several
> Boost Intrusive containers, flex_string, segmented_array and
> a few others.
> To the best of my knowledge Boost Serialization doesn't take
> advantage of ::std::move.
> I've checked the 1.48 code also.
>> It's usually very easy to build something that beats benchmarks of a
>> more-general system.
> Well, this is the first time I've had an archive with the tests that
> I link to, so at least think that is a step in the right direction.

No argument; I'm just sayin'.

>> 3. That "our approach writes marshalling functions based on the content
>> of the types involved" does not explain how you get past the private
>> member access barrier. The only legal technique I've seen for that
>> is at, and Boost.Serialization should
>> probably have support for that approach.
> C++ Middleware Writer users add function prototypes to their
> classes. The first two links on this page --
> show an example. In that example the marshalling functions are
> virtual. In general they aren't required to be.

That's a fundamentally intrusive design; being able to add serialization
non-intrusively was a major design goal for Boost.Serialization.

Dave Abrahams
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at