From: Robert Ramey (ramey_at_[hidden])
Date: 2005-08-12 16:26:59
There wasn't really enough data to pin anything down. Its going to take a
significant effort to gather such data. Which raises an intereing question:
Boost has a strong infrastructure for testing library correctness. This
infrastructure permits comparison of libraries accross different
If someone had nothing else to do, it would be interesting to develop a
parallel infrastructure for testing performance.
questions are regularly posted to the list regarding performance of all the
libraries. Usually, any data is largely anecdotal. To really address
these questions, something more is needed.
Jeff Flinn wrote:
> "Robert Ramey" <ramey_at_[hidden]> wrote in message
>> I did notice this article and took note of the claim.
>> This is a very interesting topic to me and one that merits a "science
>> project". I invested much effort in making sure code was generated at
>> compile time whenever possible so I would be disappointed at such a
>> My past experience in this area is that one really has to undertake a
>> serious effort to gather this kind of data. I've been through before
>> with my sort program (www.rrsd.com) and now believe that there is no
>> short cut in this area. Anecdotal information is usually very
>> misleading. I would guess there is likely a few areas where
>> performance is getting bogged down. I might suspect the stl used in
>> object tracking. However, in the past, whenever I really looked at
>> these questions with a good statistical profiler, I've always found
>> that bottle necks in places where I never would have suspected.
>> So, this is an interesting area which needs a serious look.
> I haven't read the article, but, IIRC there was discussion elsewhere
> concerning the overhead involved in reconstructing the
> xxx_(i|o)archive for similar message passing applications. Could this
> be the issue here as well?
> Jeff Flinn
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk