Re: [boost] Comparison of serialization results
I found an error that affects two of my test cases -- not comparing apples to apples -- so have updated the page I linked to and the archive with the tests. Only one of the tests showed different results after the change. Rather than claiming the Boost Serialization version of the test was over 3 times slower than the Ebenezer version, I now claim it is over 2.3 times slower. Dave Abrahams:
A few:
1. The claim that you provide "full generation of marshalling functions" is a little hard to swallow. In principle, it's impossible to know based on a class declaration what to serialize, and how to serialize it.
True. In order to turn off the default generation of marshalling code, one can place a comment like this: // hand_written_marshalling_code in the body of a class. Instances of that class can still be marshalled if you provide the expected marshalling functions yourself.
2. If you are going to compare yourself to Boost.Serialization, it would be a good idea to replicate all of that library's tests with your own system, to demonstrate that you cover the same expressive range.
We don't cover the same range, but are working to add to the reperoire. We do have support for some things that the Boost library doesn't: iterator_range, sub_range, several Boost Intrusive containers, flex_string, segmented_array and a few others. To the best of my knowledge Boost Serialization doesn't take advantage of ::std::move. http://boost.2283326.n4.nabble.com/Serialization-and-std-move-td2598382.html I've checked the 1.48 code also.
It's usually very easy to build something that beats benchmarks of a more-general system.
Well, this is the first time I've had an archive with the tests that I link to, so at least think that is a step in the right direction.
3. That "our approach writes marshalling functions based on the content of the types involved" does not explain how you get past the private member access barrier. 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.
C++ Middleware Writer users add function prototypes to their classes. The first two links on this page -- http://webEbenezer.net/rbtree_marshalling.html show an example. In that example the marshalling functions are virtual. In general they aren't required to be. Regards, Brian Wood Ebenezer Enterprises http://webEbenezer.net
on Thu Dec 29 2011, Brian Wood <woodbrian77-AT-gmail.com> wrote:
I found an error that affects two of my test cases -- not comparing apples to apples -- so have updated the page I linked to and the archive with the tests. Only one of the tests showed different results after the change. Rather than claiming the Boost Serialization version of the test was over 3 times slower than the Ebenezer version, I now claim it is over 2.3 times slower.
Dave Abrahams:
A few:
1. The claim that you provide "full generation of marshalling functions" is a little hard to swallow. In principle, it's impossible to know based on a class declaration what to serialize, and how to serialize it.
True. In order to turn off the default generation of marshalling code, one can place a comment like this:
// hand_written_marshalling_code
in the body of a class. Instances of that class can still be marshalled if you provide the expected marshalling functions yourself.
No post-hock marshalling? You should be able to add marshalling to a class without modifying its declaration.
2. If you are going to compare yourself to Boost.Serialization, it would be a good idea to replicate all of that library's tests with your own system, to demonstrate that you cover the same expressive range.
We don't cover the same range, but are working to add to the reperoire.
Then you should demonstrate which things you do cover.
We do have support for some things that the Boost library doesn't: iterator_range, sub_range, several Boost Intrusive containers, flex_string, segmented_array and a few others.
To the best of my knowledge Boost Serialization doesn't take advantage of ::std::move. http://boost.2283326.n4.nabble.com/Serialization-and-std-move-td2598382.html I've checked the 1.48 code also.
It's usually very easy to build something that beats benchmarks of a more-general system.
Well, this is the first time I've had an archive with the tests that I link to, so at least think that is a step in the right direction.
No argument; I'm just sayin'.
3. That "our approach writes marshalling functions based on the content of the types involved" does not explain how you get past the private member access barrier. 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.
C++ Middleware Writer users add function prototypes to their classes. The first two links on this page -- http://webEbenezer.net/rbtree_marshalling.html show an example. In that example the marshalling functions are virtual. In general they aren't required to be.
That's a fundamentally intrusive design; being able to add serialization non-intrusively was a major design goal for Boost.Serialization. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (2)
-
Brian Wood -
Dave Abrahams