Re: Avoid stack frame setup in performance critical routines using tail calls
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael.paquier@gmail.com>, Tomas Vondra <tv@fuzzy.cz>
Date: 2023-07-21T02:03:46Z
Lists: pgsql-hackers
Attachments
- palloc_performance_chart.png (image/png)
On Wed, 19 Jul 2023 at 20:52, Andres Freund <andres@anarazel.de> wrote: > 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've only just briefly read through the updated patch, but I did take it for a spin to see what sort of improvements I can get from it. The attached graph shows the time in seconds that it took for each allocator to allocate 10GBs of memory resetting the context once 1MB is allocated. The data point for aset with 32-byte chunks takes master 1.697 seconds and with both patches, it goes down to 1.264, which is a 34% increase in performance. It's pretty nice that we can hide the AllocSizeIsValid tests inside the allocChunkLimit path and pretty good that we can skip the NULL checks in most cases since we're not having to check for malloc failure unless we malloc a new block. I'll reply back with a more detailed review next week. David
Commits
-
Optimize GenerationAlloc() and SlabAlloc()
- a0cd95448067 17.0 landed
-
Refactor AllocSetAlloc(), separating hot and cold paths
- 413c18401dcc 17.0 landed
-
Adjust memory allocation functions to allow sibling calls
- 743112a2e993 17.0 landed