tsbootstrap got up to 20x faster by moving fewer bytes

tsbootstrap’s bootstrap engine got dramatically faster after a redesign centered on a simple rule: don’t materialize an array if its only consumer is a reduction. According to the project’s benchmark results, every head-to-head benchmark cell now favors the fused path, with 3.1x to 20x gains on longer series. In the most stubborn case, runtime fell from 13.1 ms to 0.55 ms after the team removed Python-built seed objects.

The change came after a direct comparison with arch, a long-established econometrics library, exposed a problem that tsbootstrap’s internal regression benchmarks had missed. On a realistic workload — a few thousand replicates of a few-thousand-point series — tsbootstrap was several times slower end to end. The author says every prior release had shipped with that deficit.

At the center of the slowdown was a batched NumPy design that built all bootstrap replicates at once. For a routine job with n = 10,000 observations, B = 2,000 bootstrap replicates, and float64 storage, that meant a 160 MB tensor just to compute one summary number per replicate. The source argues this turned the workload into a memory-traffic problem, not a compute problem: data was written to DRAM, then read back once for reduction, while the useful output was only 16 kB.

On larger jobs, the memory gap widened further. At B = 50,000 on an n = 2,000 series, the materializing path peaked at 1.94 GB, versus 20 MB for the streaming path — about 97x less memory, measured on 2026-07-04 on v0.4.0. For the worked example’s shape in a stationary-block resample, measured on 2026-07-11, peak resident memory was 617 MB for materialization versus 234 MB for streaming, with 234 MB described as the bare process baseline.

Recommended reading

SQLite handled 315M daily requests on a laptop

The fix was to replace separate array-building steps with a single compiled kernel that handles each replicate in one pass: build indices, gather values, apply the reducer, and emit only the statistic. The full replicate tensor never exists on this fast path. The implementation also uses int32 resample indices instead of int64, with an explicit error if an index exceeds 32-bit range, and allows the returned simulation tensor to be stored as float32 while model fitting and reductions remain float64.

The article ties this design to a broader systems principle: keep the working set in fast memory and avoid writing large intermediates. It draws a direct comparison to FlashAttention, which the author cites as avoiding materialization of the large N × N attention matrix and delivering a 7.6x speedup on GPT-2 attention. The hardware constraints differ, but the principle is the same.

One caveat remains: the full replicate tensor is still available when users want it, and on that materializing path, tsbootstrap’s default backend is still slower than the incumbent. But on the hot path that most directly matters for reduction-heavy workloads, the redesign changed the economics from counting FLOPs to counting bytes — and the bytes were the bottleneck all along.