Subject: Re: [boost] Comparison of serialization results
From: Brian Wood (woodbrian77_at_[hidden])
Date: 2011-12-29 16:21:41
> This first came up several years ago and I spent a little time looking at
> 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
> a) first I couldn't compile them so I couldn't repeat the results.
> 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
> on streambuf to do it's i/o and the time is sensitive to things like
> 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
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk