Re: Marginal performance improvement for fast-path locking

On Thu, Nov 28, 2013 at 2:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

FWIW, I considered that approach when initially developing the feature
and came to the same conclusion.  Now we could benchmark it...

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

…and we could also benchmark this.  But I bet there are more fruitful
optimization targets elsewhere.

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