Boost logo

Boost :

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

This is a MIME encoded message.

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
> >> // I removed a section of code at the
> >>
> >> // of the Send function that flushes
> >>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
> 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
    oArch & lst;
    oFile.flush(); //oFile is an ofstream used to
                              //build oArch.
    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

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at