Matthias Troyer wrote:
Regarding the inlining: -O2 inlines all the functions that are declared as inline. -O3 in addition attempts to inline small functions that are not declared inline. I surely hope that all such small functions in the library are declared inline,
Hmm, actually I don't know that for a fact. I think I did use inline for all thse functions -but I might have overlooked some. Also, the serialization library relies heavily on mpl and other boost stuff. I havn't verified that all that imported code uses inline either. But now I think about it. Its not clear to me that's its not better to leave it off and let the compiler decide. That might better permit one to optimise for size in one compilation while optimising for speed in another. This is an open question.
Nobody who cares for performance would use text based I/O. All your benchmark shows is that the overhead of the serialization library is comparable to that of text/based I/O onto a hard disk. For this purpose you are right, the overhead can be ignored. On the other hand, my benchmark used binary I/O into files and into memory buffers, and that's where the overhead of the serialization library really hurts. A 10x slowdown is horrible and makes the library unusable for high performance applications.
I'll update my "benchmark" to use stream read/write for raw i/o comparison. Robert Ramey