Re: [boost] Comparison of serialization results

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

Robert Ramey:
> 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).

I believe you are referring to something from several years ago here.

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

This sounds like the present.  Did you download and build the archive here
--
http://webEbenezer.net/build_integration.html ?  (Also in an earlier note
today
I mentioned recent changes to the test archive here --
http://webEbenezer.net/comp/tests.tar.bz2 .)
> 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.
Yes, now it would probably not be difficult to add support for ::std::move.
I'm asking for someone to open a ticket for that so someone doesn't ask
me to. ;)
[...]
> 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.
While true that the timings aren't real far apart, I note that the
timings of the (slightly) more complicated tests are worse for the
Boost Serialization library than the simpler tests.  Real uses have
more than a vector<deque<double> > of complication.  So there
may be a compounding effect, but I'm just speculating.
> Finally, I think that the scale and breadth of brian's library is much,
much
> smaller than boost serialization library.
The breadth is smaller.  I don't support text or XML based serialization.
> 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.
While the distribution models are different, I think the binary part of
the Boost Serialization library is comparable to the Ebenezer approach.
Thanks for mentioning the distribution model.
-- 
Brian Wood
Ebenezer Enterprises
http://webEbenezer.net