On Mon, Jul 27, 2026 at 7:11 PM David Rowley <[email protected]> wrote:
> 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. > +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>
