The performance of <algorithm>.

[Richard B. Kreckel]

Hi!

On Thu, 20 Nov 2003, Benjamin Kosnik wrote:
[...]
> If you could provide more detail, it would be helpful.

All right, here we go:

#include <algorithm>
#include <functional>
#include <vector>
using namespace std;

struct A { virtual void someaction(); };

void test1(vector<A*>& av)
{
#if 1
    for_each(av.begin(), av.end(), mem_fun(&A::someaction));
#else
    for (vector<A*>::const_iterator i=av.begin(); i!=av.end(); ++i) {
	(*i)->someaction();
    }
#endif
}

Compile with -O2 (or higher fancy settings), disassemble, choose the other
version, compile again, disassemble again, compare, then PANIC!!!  ;-)

[...]
> >Maybe this is a more general question: I recently got the impression that
> >it does not seem possible to code efficiently using GCC's <functional> and
> ><algorithm> in contradiction to what all the books seem to claim.  Is that
> >gonna change some day?
>
> Well, if we can make the runtime better via feedback like yours, we'll
> do it. If this turns out to be a compiler issue (inlining seems to
> change with every release, so perhaps it's fixed in mainline with
> unit-at-a-time) then you might have to file an optimization PR in
> bugzilla.

I find it amazing that as soon as you start using mem_fun, bind2nd,
compose1, and all this idiomatically really wonderful stuff the compiler
starts swapping like a wounded moth and (which is worse) the performance
creeps.  I'm sure others are reading their assembler output, too, and must
have noticed.  Something is fundamentally wrong here.  What is it?

Cheers
   -richy.
-- 
Richard B. Kreckel
<Richard.Kreckel@GiNaC.DE>
<http://www.ginac.de/~kreckel/>