On Mon, 27 Jul 2026 at 22:18, Heikki Linnakangas <[email protected]> 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
