Re: Remove redundant strlen call in ReplicationSlotValidateName

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com>, Japin Li <japinli(at)hotmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Remove redundant strlen call in ReplicationSlotValidateName
Date: 2021-07-19 00:23:19
Message-ID: CAHut+PsPTsw4=dX8BSBFXsv6epcSeAVzu8oYDevi5t-QKWBWrw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jul 18, 2021 at 11:09 PM Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote:

> ...
>
I did the patch, but to my surprise, the results weren't so good.
> Despite that claiming a tiny improvement in performance, I didn't expect
> any slowdown.
> I put a counter in pg_regress.c, summing the results of each test and did
> it three times for HEAD and for the patch.
> Some tests were better, but others were bad.
> Tests comments per example, show 180%, combocid 174%, dbize 165%, xmlmap
> 136%, lock 134%.
>
> ... ...
>
> So I'm posting the patch here, merely as an illustration of my findings.
> Perhaps someone with a better understanding of the process of translating
> C to asm can have an explanation.
> Is it worth it to change only where there has been improvement?
>
>
My guess is that your hypothetical performance improvement has been
completely swamped by the natural variations of each run.

For example,
drop_if_exists 115 84 83 94
138 63 57 86 109,30%

Those numbers are all over the place, so I doubt the results are really
saying anything at all about what is better/worse, because I think you have
zero chance to notice a couple of nanoseconds of improvement within the
noise when each run is varying from 57 to 138 ms.

IMO the only conclusion you can draw from your results is that any
performance gain is too small to be observable.

------
Kind Regards,
Peter Smith.
Fujitsu Australia

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yugo NAGATA 2021-07-19 00:24:30 Re: Implementing Incremental View Maintenance
Previous Message David Fetter 2021-07-18 23:42:37 Re: [PATCH] Allow multiple recursive self-references