Performance of find methods, comparison with linear search

[Renaud Detry]

> the counter wasn't the key change.  the key change was that i printed
> out the result.  before, the loop provided no side-effect at all, the
> result was assigned within a scoped block and then never used.   i
> believe the compiler was smart enough to optimise out the entire loop
> as a noop

That's a good catch! Somehow my version of GCC (i386 darwin 4.0)
doesn't go that far...

btw:

> Can you adjust the tests to ensure that they aren't optimised out
> entirely?  Is this checked into the libkdtree++ repo yet?

I guess you figured it by now, but the iterative_linear_find_nearest
seems to be the only loop that was entirely optimized. Accumulating
the mindist's in a double seems to be the cheapest way to force the
loop.


Small comment on the test_kdtree.cpp that is in the repository:

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
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.

Best,
Renaud.