Boost logo

Boost :

From: bwood (brass_at_[hidden])
Date: 2005-11-16 19:17:06

This is a MIME encoded message.

Content-Type: text/plain
Content-Transfer-Encoding: 7bit

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
>> 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
>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
have a
>hard time believing that "Ebenezer" can compete with
> - Has an extensive unit-test suite and compiles on a broad range of

> platforms/compilers
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, 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, gregod at, cpdaniel at, john at