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

On Mon, Jul 27, 2026 at 7:11 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

> 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.
>

+1. While the simple example shows good performance, I agree with David
that having actual performance numbers and a script would be helpful here.

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

--
*Jeevan Chalke*
*Senior Principal Engineer, Engineering Manager*
*Product Development*

enterprisedb.com <https://www.enterprisedb.com>