Re: Avoid stack frame setup in performance critical routines using tail calls

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: David Rowley <dgrowleyml@gmail.com>, pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael.paquier@gmail.com>
Cc: Tomas Vondra <tv@fuzzy.cz>
Date: 2023-07-19T08:52:36Z
Lists: pgsql-hackers

Attachments

Hi,

David and I were chatting about this patch, in the context of his bump
allocator patch.  Attached is a rebased version that is also split up into two
steps, and a bit more polished.

I wasn't sure what a good test was. I ended up measuring
  COPY pgbench_accounts TO '/dev/null' WITH (FORMAT 'binary');
of a scale 1 database with pgbench:

c=1;pgbench -q -i -s1 && pgbench  -n -c$c -j$c -t100 -f <(echo "COPY pgbench_accounts TO '/dev/null' WITH (FORMAT 'binary');")

	average latency
HEAD:   33.865 ms
01:     32.820 ms
02:     29.934 ms

The server was pinned to the one core, turbo mode disabled.  That's a pretty
nice win, I'd say.  And I don't think this is actually the most allocator
bound workload, I just tried something fairly random...


Greetings,

Andres Freund

Commits

  1. Optimize GenerationAlloc() and SlabAlloc()

  2. Refactor AllocSetAlloc(), separating hot and cold paths

  3. Adjust memory allocation functions to allow sibling calls