MIME-Version: 1.0
References: 
 <CAEudQApbWon+3Eb9x4WW_D-JkSt2mvfx99dXu9VZ4AeCuTh=fw@mail.gmail.com>
 <CAEudQApEfvhNT1fEPURzVcQH7G0A1ukh_ugoCGaErV6_dbndCQ@mail.gmail.com>
 <CAF+pBj_RS2KErTqQ6ORXjhVzmukG7Ve0wHU1Kq56xjJfFKwVqA@mail.gmail.com>
 <CAEudQAptRymgvmd5hQb2mk-Ft89XcSo_xvC74kv4JBA9v=D4Sg@mail.gmail.com>
 <CAF+pBj-K2bgNQRc9ih01WFmAWUaQtVbS37jLtYdYh5LOwOkF6A@mail.gmail.com>
 <CAEudQApqk6DXWgqSBdHyH7+wSxJuk7D-DwkGODUcGkUWpYu0UA@mail.gmail.com>
 <CAF+pBj-pAGnTh2un8RGcDqSYuMnwGhXv5_MteB77FNjf-Af=tg@mail.gmail.com>
 <CAF+pBj87nrr1jGadSRqZrhik+Y9T7V5e7177MOJX6=8KjUgOkA@mail.gmail.com>
In-Reply-To: 
 <CAF+pBj87nrr1jGadSRqZrhik+Y9T7V5e7177MOJX6=8KjUgOkA@mail.gmail.com>
From: Ranier Vilela <ranier.vf@gmail.com>
Date: Thu, 12 Mar 2026 16:27:13 -0300
Message-ID: 
 <CAEudQArY+Kb0EjL1EwdbSecerJ4DsH=ywcBA7_X7eVDrEwdVWQ@mail.gmail.com>
Subject: Re: Avoid multiple calls to memcpy (src/backend/access/index/genam.c)
To: Bryan Green <dbryan.green@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000000c446a064cd8bed9"
Archived-At: 
 <https://www.postgresql.org/message-id/CAEudQArY%2BKb0EjL1EwdbSecerJ4DsH%3DywcBA7_X7eVDrEwdVWQ%40mail.gmail.com>
Precedence: bulk

--0000000000000c446a064cd8bed9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Em qui., 12 de mar. de 2026 =C3=A0s 16:21, Bryan Green <dbryan.green@gmail.=
com>
escreveu:

> I modified your memcpy1.c program to not inline the version functions.  I
> changed the memcpy function
> call in version 1, added volatile to keep some DCE opportunities from
> happening and added a range
> of N values to keep the compiler from specializing the code for N =3D 4.
> Before it did DCE and the test1
> function was just a ret.
>
> The interesting issue is the use of malloc versus the stack.  The use of
> malloc will probably track closer
> with PG's use of palloc so I would say in that case this is an
> optimization.  It might be fun to compile PG
> with and without the patch (in debug mode) and actually see what gets
> generated for this function.
>
> Here are the results I got using your modified benchmark:
> --- stack allocated ---
> stack  n=3D1  v1(patch): 49721599 ns  v2(original): 21477302 ns  ratio:
> 2.315  original wins
> stack  n=3D2  v1(patch): 52065462 ns  v2(original): 28765199 ns  ratio:
> 1.810  original wins
> stack  n=3D3  v1(patch): 58914958 ns  v2(original): 39726110 ns  ratio:
> 1.483  original wins
> stack  n=3D4  v1(patch): 64585275 ns  v2(original): 47046397 ns  ratio:
> 1.373  original wins
> stack  n=3D5  v1(patch): 73929844 ns  v2(original): 58588698 ns  ratio:
> 1.262  original wins
> stack  n=3D6  v1(patch): 95465376 ns  v2(original): 67807817 ns  ratio:
> 1.408  original wins
> stack  n=3D7  v1(patch): 86910226 ns  v2(original): 76999488 ns  ratio:
> 1.129  original wins
> stack  n=3D8  v1(patch): 107765417 ns  v2(original): 86046016 ns  ratio:
> 1.252  original wins
>
> --- malloc allocated ---
> malloc n=3D1  v1(patch): 133283824 ns  v2(original): 141361091 ns  ratio:
> 0.943  patch wins
> malloc n=3D2  v1(patch): 145625895 ns  v2(original): 180912711 ns  ratio:
> 0.805  patch wins
> malloc n=3D3  v1(patch): 153975594 ns  v2(original): 228459879 ns  ratio:
> 0.674  patch wins
> malloc n=3D4  v1(patch): 154483094 ns  v2(original): 248157408 ns  ratio:
> 0.623  patch wins
> malloc n=3D5  v1(patch): 157710598 ns  v2(original): 298795018 ns  ratio:
> 0.528  patch wins
> malloc n=3D6  v1(patch): 165196636 ns  v2(original): 332940132 ns  ratio:
> 0.496  patch wins
> malloc n=3D7  v1(patch): 169576370 ns  v2(original): 358438778 ns  ratio:
> 0.473  patch wins
> malloc n=3D8  v1(patch): 184463815 ns  v2(original): 403721513 ns  ratio:
> 0.457  patch wins
>
Thanks for your attention and tests.

I think that patch can continue then.

best regards,
Ranier Vilela

--0000000000000c446a064cd8bed9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">Em qui., 12 de =
mar. de 2026 =C3=A0s 16:21, Bryan Green &lt;<a href=3D"mailto:dbryan.green@=
gmail.com">dbryan.green@gmail.com</a>&gt; escreveu:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">I modified your memcpy=
1.c program to not inline the version functions.=C2=A0 I changed the memcpy=
 function<div>call in version 1, added volatile to keep some DCE opportunit=
ies from happening and added a range</div><div>of N values to keep the comp=
iler from specializing the code for N =3D 4.=C2=A0 Before it did DCE and th=
e test1=C2=A0</div><div>function was just a ret.</div><div><br></div><div>T=
he interesting issue is the use of malloc versus the stack.=C2=A0 The use o=
f malloc will probably track closer</div><div>with PG&#39;s use of palloc s=
o I would say in that case this is an optimization.=C2=A0 It might be fun t=
o compile PG</div><div>with and without the patch (in debug mode) and actua=
lly see what gets generated for this function.</div><div><br></div><div>Her=
e are the results I got using your modified benchmark:</div><div>--- stack =
allocated ---<br>stack =C2=A0n=3D1 =C2=A0v1(patch): 49721599 ns =C2=A0v2(or=
iginal): 21477302 ns =C2=A0ratio: 2.315 =C2=A0original wins<br>stack =C2=A0=
n=3D2 =C2=A0v1(patch): 52065462 ns =C2=A0v2(original): 28765199 ns =C2=A0ra=
tio: 1.810 =C2=A0original wins<br>stack =C2=A0n=3D3 =C2=A0v1(patch): 589149=
58 ns =C2=A0v2(original): 39726110 ns =C2=A0ratio: 1.483 =C2=A0original win=
s<br>stack =C2=A0n=3D4 =C2=A0v1(patch): 64585275 ns =C2=A0v2(original): 470=
46397 ns =C2=A0ratio: 1.373 =C2=A0original wins<br>stack =C2=A0n=3D5 =C2=A0=
v1(patch): 73929844 ns =C2=A0v2(original): 58588698 ns =C2=A0ratio: 1.262 =
=C2=A0original wins<br>stack =C2=A0n=3D6 =C2=A0v1(patch): 95465376 ns =C2=
=A0v2(original): 67807817 ns =C2=A0ratio: 1.408 =C2=A0original wins<br>stac=
k =C2=A0n=3D7 =C2=A0v1(patch): 86910226 ns =C2=A0v2(original): 76999488 ns =
=C2=A0ratio: 1.129 =C2=A0original wins<br>stack =C2=A0n=3D8 =C2=A0v1(patch)=
: 107765417 ns =C2=A0v2(original): 86046016 ns =C2=A0ratio: 1.252 =C2=A0ori=
ginal wins<br><br>--- malloc allocated ---<br>malloc n=3D1 =C2=A0v1(patch):=
 133283824 ns =C2=A0v2(original): 141361091 ns =C2=A0ratio: 0.943 =C2=A0pat=
ch wins<br>malloc n=3D2 =C2=A0v1(patch): 145625895 ns =C2=A0v2(original): 1=
80912711 ns =C2=A0ratio: 0.805 =C2=A0patch wins<br>malloc n=3D3 =C2=A0v1(pa=
tch): 153975594 ns =C2=A0v2(original): 228459879 ns =C2=A0ratio: 0.674 =C2=
=A0patch wins<br>malloc n=3D4 =C2=A0v1(patch): 154483094 ns =C2=A0v2(origin=
al): 248157408 ns =C2=A0ratio: 0.623 =C2=A0patch wins<br>malloc n=3D5 =C2=
=A0v1(patch): 157710598 ns =C2=A0v2(original): 298795018 ns =C2=A0ratio: 0.=
528 =C2=A0patch wins<br>malloc n=3D6 =C2=A0v1(patch): 165196636 ns =C2=A0v2=
(original): 332940132 ns =C2=A0ratio: 0.496 =C2=A0patch wins<br>malloc n=3D=
7 =C2=A0v1(patch): 169576370 ns =C2=A0v2(original): 358438778 ns =C2=A0rati=
o: 0.473 =C2=A0patch wins<br>malloc n=3D8 =C2=A0v1(patch): 184463815 ns =C2=
=A0v2(original): 403721513 ns =C2=A0ratio: 0.457 =C2=A0patch wins</div></di=
v></blockquote><div>Thanks for your attention and tests.</div><div><br></di=
v><div>I think that patch can continue then.</div><div><br></div><div>best =
regards,</div><div>Ranier Vilela</div></div></div>

--0000000000000c446a064cd8bed9--