Re: Marginal performance improvement for fast-path locking

On Fri, Nov 29, 2013 at 12:16 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> While debugging the recent fastpath lock unpleasantness, I noticed that
> the code tends to use only the last few entries in the fpRelId[] arrays,
> which seemed a bit surprising.  The reason of course is the way that
> FastPathGrantRelationLock() is written: it remembers the *last* unused
> slot while scanning the array.  This ends up wasting cycles in
> FastPathUnGrantRelationLock(), as well as other places where we search
> for an existing entry, since they'll generally have to iterate to the end
> of the array to find it.  We should prefer to put entries near the front
> of the array, not the back.  (Of course, if the array is about full then
> it's going to be a wash, but in simple transactions we might only have a
> few relations with fast-path locks.)
>
> 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? I agree,the code added would be more
complex, but we could potentially drastically reduce the time for the
lookup, since only the smaller array will be mostly looked at.

Regards,

Atri


-- 
Regards,

Atri
l'apprenant