Performance of find methods, comparison with linear search

[Sylvain Bougerel]

On Nov 29, 2007 4:24 PM, Renaud Detry <renaudjdetry at airpost.net> wrote:
> GCC can inline function pointers (if the definition...); it will do it
> always with -O3; with -O2 it seems it will do it only if the function

Humm.... # man g++:

-O2 Optimize even more.  GCC performs nearly all supported optimizations that do
           not involve a space-speed tradeoff.  The compiler does not
perform loop
           unrolling or function inlining when you specify -O2.  As
compared to -O, this
           option increases both compilation time and the performance
of the generated
           code.

           -O2 turns on all optimization flags specified by -O.  It
also turns on the
           following optimization flags: -fthread-jumps -fcrossjumping
-foptimize-sib-
           ling-calls -fcse-follow-jumps  -fcse-skip-blocks -fgcse
-fgcse-lm -fexpen-
           sive-optimizations -frerun-cse-after-loop -fcaller-saves
-fpeephole2 -fsched-
           ule-insns  -fschedule-insns2 -fsched-interblock
-fsched-spec -fregmove
           -fstrict-aliasing -fstrict-overflow
-fdelete-null-pointer-checks -fre-
           order-blocks  -freorder-functions -falign-functions  -falign-jumps
           -falign-loops  -falign-labels -ftree-vrp -ftree-pre

The "inline-ing" you seems to see in -O2 comes from something else
IMHO. Inline-ing only kicks-in with -O3, from the man:

-O3 Optimize yet more.  -O3 turns on all optimizations specified by -O2 and also
           turns on the -finline-functions, -funswitch-loops and
-fgcse-after-reload
           options.


> is explicitly declared inline. This issue does not happen with a
> functor of course. The performance loss is huge with a non-inline
> accessor, so IMHO tac should be inline in the example.

This is a good point, can you commit it? Otherwise I'll do it tomorrow.

- Sylvain