Re: [boost] Comparison of serialization results

Subject: Re: [boost] Comparison of serialization results
From: Robert Ramey (ramey_at_[hidden])
Date: 2011-12-28 16:04:43

Dave Abrahams wrote:
> on Tue Dec 27 2011, Brian Wood <woodbrian77-AT-gmail.com> wrote:

This first came up several years ago and I spent a little time looking at 
it.
I was sort of intrigued in that the usage of TMP driven inline code should
be optimal for cases where tracking wasn't involved.  And in these test
cases there isn't any tracking.  So I looked a little at the tests on the 
page.

a) first I couldn't compile them so I couldn't repeat the results. 
Something
was missing (I forget what now).

b) so I inspected the code. My conclusion was that the being used was
that in the i/o itself rather than the serialization.  Boost serialization 
relies
on streambuf to do it's i/o and the time is sensitive to things like buffer 
sizes
etc.  It seems that brian's code uses some other method which whose
source isn't visible to me.  (SendBuffer, etc).

c) Brian did point out some cases where boost serialize could be improved
particularly using hints in std collections.  These were incorporated.  I 
also
implemented the binary i/o in terms of streambuf rather than stream which
was a noticible improvement.

d) I also implemented some performance tests which are included in the 
library
and run with bjam.  I didn't really flesh these out since there wasn't that
much interest.  Running performance tests in the boost test suite would
have been a problem so the applicability was limited.

e) So, given tat the timings aren't that far apart, and lacking any other
information, I'm inclined to attribute any discrepencies to the way i/o is 
handled
in the different systems.  If one had nothing else to do he could make
a replacement for streambuf which focused on fast i/o perhaps at the
expense of portability.  In particular, an asyncronous memory mapped i/o
library might be an interesting addition to boost. And that would be cool
to plug in the serialization library.

Finally, I think that the scale and breadth of brian's library is much, much
smaller than boost serialization library. Then there is the fact that the
distribution model is totally different than that of boost and open source
libraries in general.  I just don't see how these packages/approaches
could be considered comparable in any way.

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

I looked at this - extremely clever - I expect nothing less from you!

Actually, too clever in my opinion.  Basically we have private: which means 
"don't let anyone outside of here access this !".  This is pretty clear. 
Then we add: friend boost::serialization::access "which means - make an 
exception to the above for boost::serialization!".  Which is also pretty 
clear.  But your method would let
me get my hands on someone else's private members without their giving 
permission.  If this were to happen
to me, I don't think I'd like it.

Users have the option of doing this if they want to avoid having to use the 
friend declaration in some special cases.  So I would be skeptical that 
something like this would be a good thing to include in the serialization 
library.

Robert Ramey