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

From: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tomas Vondra <tv(at)fuzzy(dot)cz>
Subject: Re: Avoid stack frame setup in performance critical routines using tail calls
Date: 2023-08-08 11:18:51
Message-ID: CAFBsxsGdLkfqPdCFzQS-G7Gp6GXT44gT9M=3NYP67Dr3e_gWAA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 19, 2023 at 3:53 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> 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.

Here is a quick test -- something similar was used to measure the slab
improvements last cycle. With radix tree v37 0001-0011 from [1],

create extension bench_radix_tree;
select avg(load_ms) from generate_series(1,100) x(x), lateral (select *
from bench_load_random_int(100 * 1000 * (1+x-x))) a;

The backend was pinned and turbo off. Perf runs were separate from timed
runs. I included 0002 for completeness.

v37
avg
---------------------
27.0400000000000000

32.42% postgres bench_radix_tree.so [.] rt_recursive_set
21.60% postgres postgres [.] SlabAlloc
11.06% postgres [unknown] [k] 0xffffffff930018f7
10.49% postgres bench_radix_tree.so [.] rt_extend_down
7.07% postgres postgres [.] MemoryContextAlloc
4.83% postgres bench_radix_tree.so [.] rt_node_insert_inner
2.19% postgres bench_radix_tree.so [.] rt_grow_node_48
2.16% postgres bench_radix_tree.so [.] rt_set.isra.0
1.50% postgres bench_radix_tree.so [.] MemoryContextAlloc(at)plt

v37 + palloc sibling calls
avg
---------------------
26.0700000000000000

v37 + palloc sibling calls + opt aset
avg
---------------------
26.0900000000000000

33.78% postgres bench_radix_tree.so [.] rt_recursive_set
23.04% postgres postgres [.] SlabAlloc
11.43% postgres [unknown] [k] 0xffffffff930018f7
11.05% postgres bench_radix_tree.so [.] rt_extend_down
5.52% postgres bench_radix_tree.so [.] rt_node_insert_inner
2.47% postgres bench_radix_tree.so [.] rt_set.isra.0
2.30% postgres bench_radix_tree.so [.] rt_grow_node_48
1.88% postgres postgres [.] MemoryContextAlloc
1.44% postgres bench_radix_tree.so [.] MemoryContextAlloc(at)plt

It's nice to see MemoryContextAlloc go down in the profile.

[1]
https://www.postgresql.org/message-id/CAD21AoA3gS45DFMOyTE-Wm4fu+BYzsYPVcSMYggLxwm40cGHZg@mail.gmail.com

--
John Naylor
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2023-08-08 11:24:24 Re: How to build a new grammer for pg?
Previous Message Hayato Kuroda (Fujitsu) 2023-08-08 10:43:06 Suppress generating WAL records during the upgrade