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