Re: [PATCH] Speed up repeat() for larger counts

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>, ChenhuiMo <chenhuimo(dot)mch(at)qq(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Speed up repeat() for larger counts
Date: 2026-07-27 13:41:13
Message-ID: CAApHDvoH4bnkHH1DHYGdMFPbMR1_HMUWSR1yYPMFPqJ+_Y4ohQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 27 Jul 2026 at 22:18, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> Beyond certain size, I'd guess it might even become slower, if the
> string no longer fits in the L0 CPU cache for example. Also, if the
> fast-path used a constant size, like 64 bytes, maybe the compiler could
> optimize the memcpy() into a single SIMD instruction or something.

I read this earlier and wondered the same thing. The thing that might
save it would be the hardware prefetcher seeing the linear memory
access and loading the cachelines back again before there's a stall.
However, that assumes memory can keep up with a modern memcpy(), and I
believe that a good AVX512 memcpy could well outpace even DDR5 RAM
speed. Capping the chunks at something L1-sized might solve that. It
might be worth the author looking at what I did with
ESCAPE_JSON_FLUSH_AFTER in json.c. Benchmarks for that in [1]. I
expect it'll be diminishing returns with memcpy sizes beyond a handful
of kilobytes.

It does feel like a rather incomplete performance patch as it doesn't
come with any results to demonstrate that it actually has a positive
impact on performance. It would be good to see a script posted here
that tests various input lengths and repeat counts that people could
easily run to see if they get the same improvement on their hardware.

David

[1] https://postgr.es/m/CAApHDvpi7FkbNenAB%2BXKPtejDmVMx7iEfxKH%3DLN_rZDGvLoGcA%40mail.gmail.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-07-27 13:43:51 Re: Fix missing FORMAT when deparsing JSON_ARRAY(query)
Previous Message Aleksander Alekseev 2026-07-27 13:36:24 Re: aio tests failing on newer Linux kernels