Re: A few more opportunities to use TupleTableSlotOps fields

On Tue, May 21, 2019 at 10:48 AM Antonin Houska <ah(at)cybertec(dot)at> wrote:
> Do you refer to the fact that for example the address of
>
> tts_virtual_clear(dstslot);
>
> is immediately available in the text section while in this case
>
> dstslot->tts_ops->clear(dstslot);
>
> the CPU first needs to fetch the address of tts_ops and also that of the
> ->clear function?

Yes. And since tts_virtual_clear() is marked static, it seems like it
might even possible for it to inline that function at compile time.

> I admit I didn't think about this problem. Nevertheless I imagine that due to
> constness of the variables like TTSOpsVirtual (and due to several other const
> declarations) the compiler might be able to compute the address of the
> tts_ops->clear() expression. Thus the only extra work for the CPU would be to
> fetch tts_ops from dstslot, but that should not be a big deal because other
> fields of dstslot are accessed by the surrounding code (so all of them might
> be available in the CPU cache).

I think the issue is pipeline stalls. If the compiler can see a
direct call coming up, it can start fetching the instructions from the
target address. If it sees an indirect call, that's probably harder
to do.

But really, I'm not an expect on this area. I would write the code as
Andres did on the general principle of making things as easy for the
compiler and CPU as possible, but I do not know how much it really
matters. Andres probably does know...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company