Re: [boost] [serialization] fast array serialization (10x speedup)

From: Ian McCulloch (ianmcc_at_[hidden])
Date: 2005-11-24 19:29:42

Robert Ramey wrote:

> Ian McCulloch wrote:
> 
>> Besides, is the boost iostreams library really much slower than a
>> hand-coded buffer?
> 
> I'm pretty confident that its much, much slower, but this will remain
> in dispute until someone runs the code with a profiler.

Or do a benchmark of writing N items into a iostreams buffer versus N items
into a trivial buffer.  I actually just tried this, and the difference was
a factor 2 for both in-cache and out-of-cache.  g++ 3.4.4, AMD64.

For out-of-cache, the iostreams was a factor 7 slower than a memcpy(), and
the trivial buffer was factor 3.4 slower.  For in-cache, the iostreams was
a factor 30 slower than a memcpy() and the trivial buffer was a factor 15
slower.  Benchmark code attached.  This was the first time I used
boost::iostreams so I am not sure if I did it correctly.  I used a
stream<back_insert_device<vector<unsigned char> > >, and the write() member
function.

> 
>> Anyway, this is a side issue.  The main point is:
>>
>> David Abrahams wrote:
>>>   ,----
>>>   | For many archive formats and common datatypes there exist APIs
>>>   | that can quickly read or write contiguous sequences of those
>>>   types | all at once (**).  Reading or writing such a sequence by
>>>   | separately reading or writing each element (as the serialization
>>>   | library currently does) can be an order of magnitude more
>>>   | expensive.
>>>   `----
> 
> Sorry - that's NOT the main point.
> 
> The main point is - do enhancement for special cases have to be
> incorporated into the the core code so that everybody else
> is obligated to use it?  What are the advantages and
> disadvantages of doing so?

'Recommended' I can believe, but 'Obligated'?  Why?

> 
> No one is disputing that it desireable to be able to extend
> the library for these special circumstances.
> 
> 
>> If there is to be any possibility of targetting an archive to this
>> format, then array support is crucial.
> 
> Then just make an archive which does it- what's stopping you?

None of the existing container serialization functions would make use of it,
and I have no desire to rewrite and maintain specialized versions of them.

This isn't just a specialized case applying to just a few archive types and
just a few user defined types.  It is wide-ranging and applies a
potentially large number of archive types and a very large number of
serializable objects, including standard library components and existing
boost components.

Anyway, it is clear to me that my arguments are not helping in the
slightest, and the probability of convincing you that what we are trying to
do is both worthwhile but problematic without some form of array support in
the serialization lib appears to be zero.  So I will not waste your time
and mine any further by continuing to post to this thread.

Regards,
Ian