Re: Marginal performance improvement for fast-path locking

Atri Sharma <atri(dot)jiit(at)gmail(dot)com> writes:
> On Fri, Nov 29, 2013 at 12:16 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> We could add an extra test in FastPathGrantRelationLock's loop to make
>> it remember the first unused slot rather than the last one, but that
>> would add some cycles there, partially negating any benefit. Instead
>> I propose that we reverse the direction of the search loop, as attached.

> Nice idea, but would not be making an extra array just to hold the hot
> entries be a better idea?

Well, the array isn't so large that there's going to be value in
complicating the searches.

I did think about instituting a rule that all valid entries must be
consecutive at the front, but it's far from clear that the extra logic
needed to maintain that invariant would cost less than what's saved.
The attraction of the patch I propose here is that it's zero extra
cost to get some savings.

One other thing we could do if we wanted to micro-optimize here would
be to fetch the fpLockBits value into a local register; the existing
coding most likely reads it out of the PGPROC again on every iteration.
You could further imagine coding the search loops like

for (f = 0, bits = proc->fpLockBits; bits != 0; f++, bits >>= 3)
{
if (bits & 7 != 0) do something with this slot;
}

so that you'd fall out of the loop as soon as there were no later
occupied slots. But, again, this is adding complexity and cycles
for hypothetical benefit, so it'd be nicer if we could measure
some actual speedup before doing that.

regards, tom lane