"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> Gregory Stark <stark@enterprisedb.com> writes:
>> 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.
>
> The compiler can't optimize away those conditionals, and even if the
> hardware can predict them accurately, one predicted jump has to be
> faster than five successive ones. The branch-prediction hardware works
> for function pointer calls too (else C++ would be seriously slow).
That's not really the point. The problem is that the compiler usually can't
deduce which function you're calling or even which set of functions you might
be calling. So, for example, the compiler will have trouble determining which
variables may be untouched over the function call and thus not have to be
reloaded into registers.
Again though, I really don't think it matters. It might be 1% faster or 1%
slower but HeapSatisfiesVisibility is itself only going to be a small fraction
of the total time and so even on a heavily cpu-bound test we're talking about
fractions of a percent either way. If it lets us do one algorithmic
improvement we couldn't otherwise do the gain from that flexibility down the
line will be many orders of magnitude larger and more important than a small
microptimization.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com
