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

On 27/07/2026 10:31, Jeevan Chalke wrote:
> Hello ChenhuiMo,
>
> This is a really interesting optimization — doing memcpy() exponentially
> is a great idea for larger counts. My main use case for repeat() is
> generating large files and padding, where count is usually large, so
> this change helps exactly the workload I care about.
>
> That said, I'm not entirely sure how common this usage pattern is in
> general production workloads, so I was initially unsure whether the
> added complexity is worth it. Setting that aside, the performance gain
> for short strings repeated a large number of times is real, so I'm fine
> with getting this in.

Yeah, probably the most common case is something like repeat('x',
1000000). It might even be worth special-casing the single-byte case and
turn that into a single memset() call.

> A few things worth looking at:
>
> 1. The magic number 8 is unexplained. The naive-loop fallback threshold
> seems quite low — should it be closer to a few dozen, say 64? I
> benchmarked a range of thresholds and counts: the doubling approach
> turns out to beat the naive loop even at very small counts (as low as 2–
> 3), so 8 already looks like a reasonable cutoff; raising it to 64 would
> likely make counts in the 8–64 range slower, not faster. Regardless of
> the exact value chosen, the constant needs a comment explaining why it
> was picked.
>
> 2. Because of the exponential growth, CHECK_FOR_INTERRUPTS() granularity
> drops off logarithmically; the later doubling steps can copy hundreds of
> MB in a single memcpy that can't be interrupted partway through. Would
> it help to cap the chunk size, say at 64–100MB? I tested this: capping
> adds only a handful of extra memcpy calls even for very large repeats,
> and the overhead was within noise; so it looks like a cheap way to bound
> worst-case interrupt latency.

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.

- Heikki