Re: Avoid stack frame setup in performance critical routines using tail calls - Mailing list pgsql-hackers

From David Rowley
Subject Re: Avoid stack frame setup in performance critical routines using tail calls
Date
Msg-id CAApHDvpHVSJqqb4B4OZLixr=CotKq-eKkbwZqvZVo_biYvUvQA@mail.gmail.com
Whole thread Raw
In response to Re: Avoid stack frame setup in performance critical routines using tail calls  (Andres Freund <andres@anarazel.de>)
Responses Re: Avoid stack frame setup in performance critical routines using tail calls
List pgsql-hackers
On Fri, 23 Feb 2024 at 11:53, Andres Freund <andres@anarazel.de> wrote:
>
> On 2024-02-23 00:46:26 +1300, David Rowley wrote:
> > In absence of anyone else looking at this, I think it's ready to go.
> > If anyone is following along and wants to review or test it, please do
> > so soon.
>
> Makes sense!

I pushed the 0001 and 0002 patches today.

I switched over to working on doing what you did in 0002 for
generation.c and slab.c.

See the attached patch which runs the same test as in [1] (aset.c is
just there for comparisons between slab and generation)

The attached includes some additional tuning to generation.c:

1) Changed GenerationFree() to not free() the current block when it
becomes empty. The code now just marks it as empty and reuses it.
Saves free()/malloc() cycle. Also means we can get rid of a NULL check
in GenerationAlloc().

2) Removed code in GenerationAlloc() which I felt was trying too hard
to fill the keeper, free and current block.  The changes I made here
do mean that once the keeper block becomes empty, it won't be used
again until the context is reset and gets a new allocation.  I don't
see this as a big issue as the keeper block is small anyway.

generation.c is now ~30% faster for the 8-byte test.

David

[1] https://postgr.es/m/CAApHDvqss7-a9c51nj+f9xyAr15wjLB6teHsxPe-NwLCNqiJbg@mail.gmail.com

Attachment

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Relation bulk write facility
Next
From: Bertrand Drouvot
Date:
Subject: Re: Synchronizing slots from primary to standby