Caleb Epstein wrote:

On Tue, 15 Nov 2005 02:08:52 00100 (CET), bwood <brass_at_[hidden]> 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.

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

IMHO. "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

meaningful 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 Boost.Serializationwhich:

- 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, xml) - 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. Brian