Re: [boost] serialization performance

From: bwood (brass_at_[hidden])
Date: 2005-11-10 12:03:39

This is a MIME encoded message.

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

On 10-Nov-2005 11:11:13 +0100, you wrote:
> 
> >>Some recent tests I've done that compare Ebenezer Enterprises 
> >>and Boost.serialization's performance show the 
> >>Boost.serialization approach to be 7 to 9 times slower than the 
> >>Ebenezer Enterprises approach.   I'm using Linux  2.6.12, 
> >>gcc 4.0.2 (with -O3) and a Boost.serialization library from the 
> >>release tree.  A test that compared the times to serialize/send 
> >>a list<int> took  7.4 times longer with Boost than Ebenezer.   
> >>I timed the following 
> >>Boost:
> >>      oArch & lst;    // oArch is a binary_oarchive
> >>
> >>Ebenezer:
> >>      msgs.Send(buffer, lst); // In order to compare apples to
apples, 
> >>                              // I removed a section of code at the
end
> >>
> >>                              // of the Send function that flushes
the
> >>buffer.
> 
> 
> 			        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This seems wrong to me, comparing library to library as it is written

> and as the user see's it would be much more interesting and to me
makes 
> this test pointless. If you can really just remove the flush then it 
> probably shouldnt be there in the first place or configurable by the 
> user on an archive by archive basis.
> 
To the best of my knowledge the following are functionally 
equivalent.
Boost:
    oArch & lst;
    oFile.flush();            //oFile is an ofstream used to 
                              //build oArch. 
Ebenezer: 
    msgs.Send(buffer, lst);   // where I didn't remove anything
                              // from Send's implementation.

I think as you say, whether a flush gets embedded in the Send 
function should be configurable, but right now it just is.
I'll admit it would be better if I didn't have to remove (#if 0) 
the end of the Send function, but I don't think that invalidates 
anything.  

> >>  
> >>
> >>In a second test I added a deque of int...
> >>Boost:
> >>      oArch & lst;
> >>      oArch & dq;            // std::deque<int>  dq;
> >>
> >>Ebenezer:
> >>      msgs.Send(buffer, lst, dq);
> >>
> >>In this case Boost took 9.1 times longer than Ebenezer Enterprises 
> >>approach.   If you want to run these tests with other compilers I 
> >>think that would be helpful.  I've been warned not to put too much 
> >>emphasis on numbers from gcc.
> >>
> 
> It would be interesting to see what the results are with a vanilla 
> version of your library as well as a feature by feature comparision to

> see if you really are comparing apples to apples.
> 
Both Boost and s11n.net support things like XML that Ebenezer doesn't. 

Boost in my opinion mistakenly tries to support "versioning."  We 
don't and I don't think s11n does either.  

Brian
--=_42e013419ca45fa9c6388e5bdf4c5211--