Re: [boost] "Re: serialization performance"

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

This is a MIME encoded message.

--=_b27cf2bd08acf1fbb12206d62c6c8433
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]>
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
meaningful 
>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
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
--=_b27cf2bd08acf1fbb12206d62c6c8433--