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