Re: [boost] "Re: serialization performance"

From: bwood (brass_at_[hidden])
Date: 2005-11-14 20:15:34

This is a MIME encoded message.

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

On Mon, 14 Nov 2005 22:24:41 00100 (CET), bwood <brass_at_[hidden]>
wrote:
>>
>> Either way, with or without the embedded flush code, Boost
>> serialization is less efficient than Ebenezer's Send in both
>> tests.

>What are we comparing here? You really need to give the Boost
commuinity
>more visibility into your code if you expect your arguments to be
taken
>seriously. There is nothing on http://www.webebenezer.net that
resembles
>documentation or a complete test application that can be compiled.

Hi, Caleb,

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
surface, the two lines above look similar, but the Ebenezer
line is flushing the buffer at the end of the Send function.
So the Ebenezer side is doing more functionally in less time.
(I've tested this by killing both test cases internally with a
raise(9) right after the above lines.  The Boost output
file has 0 bytes in it.  The Ebenezer file has all the data.)
So in order to compare apples to apples, I #if 0ed out the
flush code.  In that case the Boost code is 7 times slower
than the Ebenezer and both files have 0 bytes in them.
If you want the code I used in these tests I will send it
to you.  It may be that gcc doesn't optimize the Boost code
very well and another compiler would produce results that
are better.  

The documentation is not very good.  We hope to work on that.
The "Send Sample" compiled last time I checked it.  The code in
the file MsgManager.h is generated by the site.  It is not
difficult to obtain that from the site.

As far as build times, I agree that they aren't the most
important factor.  In my opinion they aren't trivial either.

Brian

--=_c00e09e871046b7b086c7a48554189f2--