Boost logo

Boost :

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

-- ?  (Also in an earlier note
I mentioned recent changes to the test archive here -- .)
> 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,
> 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

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