Re: [boost] "Re: serialization performance"
On Mon, 14 Nov 2005 22:24:41 00100 (CET), bwood <brass_at_[hidden]> wrote:
Either way, with or without the embedded flush code, Boost serialization is less efficient than Ebenezer's Send in both tests.
What are we comparing here? You really need to give the Boost commuinity more visibility into your code if you expect your arguments to be taken seriously. There is nothing on http://www.webebenezer.net that resembles documentation or a complete test application that can be compiled.
Hi, Caleb, I'm not sure if I understand your first question. I assume you read the previous posts. I compared the time it takes to serialize/send a list of ints using Boost and Ebenezer approaches. I timed the following Boost: oArch & lst; // using boost 1.33.0 Ebenezer: msgs.Send(buffer, lst); Without making any modifications to the two "vanilla" approaches, Boost takes more than twice as long than Ebenezer. On the surface, the two lines above look similar, but the Ebenezer line is flushing the buffer at the end of the Send function. So the Ebenezer side is doing more functionally in less time. (I've tested this by killing both test cases internally with a raise(9) right after the above lines. The Boost output file has 0 bytes in it. The Ebenezer file has all the data.) So in order to compare apples to apples, I #if 0ed out the flush code. In that case the Boost code is 7 times slower than the Ebenezer and both files have 0 bytes in them. If you want the code I used in these tests I will send it to you. It may be that gcc doesn't optimize the Boost code very well and another compiler would produce results that are better. The documentation is not very good. We hope to work on that. The "Send Sample" compiled last time I checked it. The code in the file MsgManager.h is generated by the site. It is not difficult to obtain that from the site. As far as build times, I agree that they aren't the most important factor. In my opinion they aren't trivial either. Brian
On Tue, 15 Nov 2005 02:08:52 00100 (CET), bwood <brass@mailvault.com> wrote:
I'm not sure if I understand your first question. I assume you read the previous posts. I compared the time it takes to serialize/send a list of ints using Boost and Ebenezer approaches. I timed the following Boost: oArch & lst; // using boost 1.33.0 Ebenezer: msgs.Send(buffer, lst);
Without making any modifications to the two "vanilla" approaches, Boost takes more than twice as long than Ebenezer. On the
Someone has proposed an enhancement for Serialization that would speed up array/vector operations by an order of magnitude. I don't think such a simple test is indicative of the overall performance or feature-set of either of these two libraries. Perhaps Boost.Serialization does not perform well with a list of ints, but Ebenezer does. Maybe Boost.Serializationperforms better with scalar values, or with tracked objects, or with the XML based archive, who knows.
It may be that gcc doesn't optimize the Boost code very well and another compiler would produce results that are better.
Who knows, but what you are benchmarking is far to small to be meaningful IMHO. The documentation is not very good. We hope to work on that.
The "Send Sample" compiled last time I checked it. The code in the file MsgManager.h is generated by the site. It is not difficult to obtain that from the site.
Perhaps you'd be so kind as to provide a link. I can't find it. Better yet make a .zip or .tar.gz file with all necessary code and such documentation as exists so people can compile and test it on their own systems without having to hunt down individual files.
As far as build times, I agree that they aren't the most important factor. In my opinion they aren't trivial either.
Features are much more important to me and I am sure many others. I have a hard time believing that "Ebenezer" can compete with Boost.Serializationwhich: - Has an extensive unit-test suite and compiles on a broad range of platforms/compilers - Supports several different archive formats (e.g. text, binary, xml) - Supports object versioning - Supoprts pointer serialization/tracking - Is not coupled to a transport (the Ebenezer example code I can see seems very socket or file-centric) Perhaps you pay a penalty for some of these features in terms of performance, but some or all are important to many users and shouldn't be dismissed lightly. -- Caleb Epstein caleb dot epstein at gmail dot com
participants (2)
-
bwood -
Caleb Epstein