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