[robert3005]

The list take by PiecewiseSequence compiled its gather kernels for every combination of piece start, piece length, list offset and output offset type (4 x 4 x 4 x 4). The kernels read each piece start and length only once per piece. The inner loop over list offsets depends only on the offset types. The take now widens the starts and lengths to u64 and dispatches only on the offset types.

The widening does not copy when the pieces are already u64, which is the type that the list take itself produces. For other widths it copies the piece arrays once. That copy is proportional to the number of pieces, not to the number of elements.

	before	after
vortex-array release __text (macOS arm64)	14,012,988 B	12,798,204 B (-1.21 MB)

[codspeed]

Merging this PR will regress 7 benchmarks

3 warnings, 1 note

⚠️ Walltime results may be unreliable

Some benchmarks used the Walltime instrument outside CodSpeed Macro Runners, which can make the results inconsistent.

Learn more about Macro Runners

See affected benchmarks

⚠️ 20 benchmarks are dominated by system calls

System calls cannot be simulated consistently and are left out of the measure. The reported value understates the real cost. Switch to the Walltime instrument to measure them.

Learn more about system calls

See affected benchmarks

⚠️ Base and head ran on different runner types

Some benchmarks with significant performance changes were compared across different runner types, so the changes might not come from the code. Run base and head on the same runner type, or use CodSpeed Macro Runners for more stable results.

Learn more about Macro Runners

Open the report in CodSpeed to investigate

ℹ️ 40 benchmarks have no flamegraph

The flamegraph wasn't generated: the symbols of the profiling trace could not be resolved, because no information about the language frames was collected.

See affected benchmarks

⚡ 9 improved benchmarks
❌ 7 regressed benchmarks
✅ 2392 untouched benchmarks
⏩ 12 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Walltime	starts_with_avx2[8, VarBin]	39.8 µs	46.6 µs	-14.6%
❌	CPU Simulation	random_i8[0.01]	103.4 µs	117 µs	-11.59%
❌	Walltime	filter_neon[8]	940 ns	1,058 ns	-11.15%
❌	Walltime	filter_neon[80]	2.6 µs	3 µs	-10.84%
❌	Walltime	add_constant_shapes_neon[(32768, PerRowConstant)]	14.6 µs	16.4 µs	-10.74%
❌	CPU Simulation	random_i128[0.01]	5.8 µs	6.5 µs	-10.71%
❌	Walltime	add_constant_shapes_neon[(32768, PerRowNullableConstant)]	15 µs	16.8 µs	-10.64%
⚡	Walltime	mul_u64_nonnull_neon	39.4 µs	20.8 µs	+89.01%
⚡	CPU Simulation	filter_powerlaw_by_mostly_false[250000]	158.2 µs	137.3 µs	+15.24%
⚡	Walltime	bitpack_blocked_compress_avx2	7.6 µs	6.7 µs	+13.38%
⚡	CPU Simulation	density_sweep_dense_runs[0.001]	61.3 µs	54.1 µs	+13.25%
⚡	CPU Simulation	filter_random_by_mostly_false[250000]	183.9 µs	162.7 µs	+13.01%
⚡	CPU Simulation	test_scan_filter[int]	3.4 ms	3 ms	+12.56%
⚡	CPU Simulation	filter_random_by_power_law[250000]	185.3 µs	165.8 µs	+11.75%
⚡	CPU Simulation	filter_powerlaw_by_power_law[250000]	185.3 µs	165.9 µs	+11.66%
⚡	CPU Simulation	filter_random_by_mostly_false[100000]	88.4 µs	80.3 µs	+10.2%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing rk/size-list-take-wide-pieces (5d7e3b8) with develop (8c680f2)²}

Footnotes

1. 12 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on develop (c88edde) during the generation of this report, so 8c680f2 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩