Re: Inlining of couple of functions in pl_exec.c improves performance

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Inlining of couple of functions in pl_exec.c improves performance
Date: 2020-05-30 05:40:39
Message-ID: CAFj8pRBn04t8nmMDiAy9f+aOJv39AjsafPCWxnOgE1kp643aqw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

so 30. 5. 2020 v 7:28 odesílatel Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>
napsal:

> On Thu, 28 May 2020 at 14:39, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> > I don't see 17% anywhere, but 3-5% is not bad.
> Did you see 3-5% only for the pi function, or did you see the same
> improvement also for the functions that I wrote ? I was getting a
> consistent result of 14-18 % on both of the VMs. Also, is your test
> machine running on Windows ? All the machines I tested were on Linux
> kernel (Ubuntu)
>

It was similar with your example too.

I tested it on Linux Fedora Core 32 - laptop T520 - I7.

I think so the effect of these patches strongly depends on CPU and compiler
- but it is micro optimization, and when I look to profiler, the bottle
neck is elsewhere.

> Below are my results for your pi_est_1() function. For this function,
> I am consistently getting 5-9 % improvement. I tested on 3 machines :
>
> gcc : 8.4.0. -O2 option
> OS : Ubuntu Bionic
>
> explain analyze select pi_est_1(10000000)
>
> 1. x86_64 laptop VM (Intel Core i7-8665U)
> HEAD : 2666 2617 2600 2630
> Patched : 2502 2409 2460 2444
>
>
> 2. x86_64 VM (Xeon Gold 6151)
> HEAD : 1664 1662 1721 1660
> Patched : 1541 1548 1537 1526
>
> 3. ARM64 VM (Kunpeng)
> HEAD : 2873 2864 2860 2861
> Patched : 2568 2513 2501 2538
>
>
> >
> > patch 0001 has sense and can help with code structure
> > patch 0002 it is little bit against simplicity, but for PLpgSQL with
> blocks structure it is correct.
>
> Here, I moved the exec_stmt code into exec_stmts() function because
> exec_stmts() was the only caller, and that function is not that big. I
> am assuming you were referring to this point when you said it is a bit
> against simplicity. But I didn't get what you implied by "but for
> PLpgSQL with blocks structure it is correct"
>

Nested statement in PLpgSQL is always a list of statements. It is not
single statement ever. So is not too strange don't have a function
execute_stmt.

Pavel

> --
> Thanks,
> -Amit Khandekar
> Huawei Technologies
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2020-05-30 06:52:24 Re: speed up unicode normalization quick check
Previous Message Amit Khandekar 2020-05-30 05:28:35 Re: Inlining of couple of functions in pl_exec.c improves performance