"Martijn van Oosterhout" <kleptog@svana.org> writes:
> On Sat, Mar 24, 2007 at 09:37:07PM +0000, Gregory Stark wrote:
>
>> It sounds like a fine idea from the point of view of flexibility. But as far
>> as faster... I guess it depends on how often HeapTupleSatisfiesVisibility is
>> used in contexts where the compiler is able to optimize away the conditionals
>> or the cpu is able to predict them accurately. I suspect in the cases where we
>> actually care--scans where it's being called thousands of times quickly--the
>> latter is quite effective.
>
> Dunno, this test by someone suggests that calling through a function
> pointer doesn't cost anything at all, if anything it's faster. Though
> that may differ on other machines obviously.
>
> http://gcc.gnu.org/ml/gcc/2004-06/msg01308.html
You should read further in that thread. The results in that post are incorect
and represent the function call being inlined differently. However even the
fixed version shows a speed improvement because the assembly to call a
function through a pointer is shorter.
In any case my point wasn't that function pointers themselves were slow. But
rather that a function call through one prevents other surrounding code from
being optimized. Since the compiler usually can't know what function you're
calling it can't know what variables it might touch. In addition to that it
can force register spills.
Personally I think worrying about micro-optimization like this is not really
useful. I think the real argument is that it makes the code cleaner and more
flexible if we want to add new types of snapshots or track more data about
snapshots.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com
