Re: [boost] Comparison of serialization results

Subject: Re: [boost] Comparison of serialization results
From: Brian Wood (woodbrian77_at_[hidden])
Date: 2011-12-29 15:33:21

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.

> 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.  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.
http://boost.2283326.n4.nabble.com/Serialization-and-std-move-td2598382.html
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.

> 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 https://gist.github.com/1528856, 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 --
http://webEbenezer.net/rbtree_marshalling.html
show an example.  In that example the marshalling functions are
virtual.  In general they aren't required to be.

Regards,
Brian Wood
Ebenezer Enterprises
http://webEbenezer.net