| From: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
|---|---|
| To: | Bryan Green <dbryan(dot)green(at)gmail(dot)com> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Avoid multiple calls to memcpy (src/backend/access/index/genam.c) |
| Date: | 2026-03-09 16:25:20 |
| Message-ID: | CAEudQAptRymgvmd5hQb2mk-Ft89XcSo_xvC74kv4JBA9v=D4Sg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Em seg., 9 de mar. de 2026 às 11:47, Bryan Green <dbryan(dot)green(at)gmail(dot)com>
escreveu:
> I created an example that is a little bit closer to the actual code and
> changed the compiler from C++ to C.
>
> It is interesting the optimization that the compiler has chosen for
> version 1 versus version 2. One calls
> memcpy and one doesn't. There is a good chance the inlining of memcpy as
> SSE+scalar per iteration
> will be faster for syscache scans-- which I believe are usually small (1-4
> keys?).
>
I doubt the inline version is better.
Clang is supported too and the code generated is much better with memcpy
one call outside of the loop.
>
> Probably the only reason to do this patch would be if N is normally large
> or if this is considered an
> improvement in code clarity without a detrimental impact on small N
> syscache scans.
> I realize you only said "possible small optimization". It might be
> worthwhile to benchmark the code for
> different values of n to determine if there is a tipping point either way?
>
In your opinion, shouldn't this be considered an optimization, even a
small one?
best regards,
Ranier Vilela
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2026-03-09 16:38:47 | Re: Refactor handling of "-only" options in pg_dump, pg_restore |
| Previous Message | Ahmed Et-tanany | 2026-03-09 16:09:13 | Re: [PATCH] Add max_logical_replication_slots GUC |