Re: [boost] Comparison of serialization results

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 <woodbrian77-AT-gmail.com> 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.
> 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.

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 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.

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
http://www.boostpro.com