From: bwood (brass_at_[hidden])
Date: 2005-11-16 19:17:06
This is a MIME encoded message.
Caleb Epstein wrote:
>On Tue, 15 Nov 2005 02:08:52 00100 (CET), bwood <brass_at_[hidden]>
>> 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
>> oArch & lst; // using boost 1.33.0
>> 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
>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
>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.
That enhancement sounds familiar. Is the aim to take
advantage of the contiguous data? WebEbenezer already
implements a limited form of this with arrays and vectors.
Certainly Boost.Serialization is better with XML. We don't
support XML and don't plan to.
>> 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
"A single accurate measurement is worth a thousand expert opinions."
I hope to add to the tests over time and add a page to webEbenezer
that will cover the results.
>> 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
>hard time believing that "Ebenezer" can compete with
> - Has an extensive unit-test suite and compiles on a broad range of
We have a variety of tests. Our approach to serialization is
different than the library approach. We don't need to port a
library to different platforms/compilers. We don't use areas
of C++ that are dark corners in terms of the code that is
output, so I think it reasonable to believe we have a broader
reach than Boost.Serialization in this respect. This is ironic
as we don't have to work hard, like Boost does, to achieve this.
> - Supports several different archive formats (e.g. text, binary,
> - Supports object versioning
S11n.net, CORBA and webEbenezer don't find a place for "versioning."
I think code like what you wrote when I asked about changing a
member's type between releases should go into a utility program that
gets run once. If you stick that code into an application it gets run
over and over, but adds nothing as far as functionality.
> - Supoprts pointer serialization/tracking
We support pointer serialization but not tracking yet.
> - Is not coupled to a transport (the Ebenezer example code I can see
> seems very socket or file-centric)
True, but that could change if needed.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk