Use PiecewiseSequence indices for FSL take

[danking]

Summary

Ports the TakeSlices-style optimization to Take(elements, PiecewiseSequenceArray) instead of introducing a value-wrapper API.

• FSL take now builds one start per selected list, a constant list length, and a constant multiplier of 1, then calls elements.take(piecewise_indices).
• Primitive, bool, decimal, VarBinView, and VarBin take paths detect PiecewiseSequenceArray indices and gather contiguous ranges only when multipliers is a constant unsigned 1; non-unit multipliers fall back through normal materialized-index take.
• Shared PiecewiseSequence execution handles general start + j * multiplier sequences, while the current optimized consumers stay explicitly contiguous.

Validation

• cargo fmt -p vortex-array
• cargo test -p vortex-array piecewise_sequence
• cargo check -p vortex-array
• cargo check -p vortex-array --benches
• git diff --check

[codspeed-hq]

Merging this PR will regress 1 benchmark

⚡ 19 improved benchmarks
❌ 1 regressed benchmark
✅ 1650 untouched benchmarks
🆕 128 new benchmarks
⏩ 52 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	true_count_vortex_buffer[128]	522.2 ns	580.6 ns	-10.05%
⚡	Simulation	take_fsl_random[1024, 1000]	15.2 ms	6 ms	×2.5
⚡	Simulation	take_fsl_nullable_random[1024, 1000]	14.8 ms	6 ms	×2.5
⚡	Simulation	take_fsl_random[256, 1000]	3.5 ms	1.5 ms	×2.2
⚡	Simulation	take_fsl_nullable_random[256, 1000]	3.4 ms	1.5 ms	×2.2
⚡	Simulation	take_fsl_random[1024, 100]	1,567.8 µs	795.2 µs	+97.14%
⚡	Simulation	take_fsl_nullable_random[1024, 100]	1,535.6 µs	805.7 µs	+90.6%
⚡	Simulation	take_fsl_random[64, 1000]	815.6 µs	457.3 µs	+78.35%
⚡	Simulation	take_fsl_random[256, 100]	418.1 µs	235.2 µs	+77.73%
⚡	Simulation	take_fsl_nullable_random[64, 1000]	811.9 µs	473.1 µs	+71.6%
⚡	Simulation	take_fsl_nullable_random[256, 100]	415.5 µs	245.6 µs	+69.17%
⚡	Simulation	take_fsl_random[16, 1000]	237.7 µs	179.4 µs	+32.5%
⚡	Simulation	take_fsl_nullable_random[16, 1000]	257.6 µs	195 µs	+32.11%
⚡	Simulation	take_fsl_random[64, 100]	123 µs	95 µs	+29.36%
⚡	Simulation	take_fsl_random[4096, 1000]	67.3 ms	54.2 ms	+24.2%
⚡	Simulation	take_fsl_nullable_random[64, 100]	131.5 µs	108.1 µs	+21.67%
⚡	Simulation	take_fsl_nullable_random[4096, 1000]	65.6 ms	54.2 ms	+20.93%
⚡	Simulation	compact_sliced[(4096, 90)]	867.8 ns	780.3 ns	+11.21%
⚡	Simulation	compact_sliced[(16384, 90)]	931.1 ns	843.6 ns	+10.37%
⚡	Simulation	take_fsl_random[4096, 100]	6.2 ms	5.6 ms	+10.17%
...	...	...	...	...	...

ℹ️ Only the first 20 benchmarks are displayed. Go to the app to view all benchmarks.

Tip

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

---

_{Comparing codex/piecewise-sequential-take (c94c4ef) with codex/piecewise-sequential-array (2b6fa3e)}

Footnotes

1. 52 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. ↩

[robert3005]

I think we have to audit the validation from the compute and verify that we do not do the work twice. We have to audit exactly but ideally we'd not validate and figure out how to make operations safe by default even given bad input.

[danking]

I cannot replicate the two benchmark slowdowns locally.

[danking]

The copy_ benchmark slowdowns are resolved by #8832

[robert3005]

we have a thing that we call Columnar

[robert3005]

Maybe minor but in this method you double validate if this succeeds

[robert3005]

I think I miss something - why we validate so hard here?

[robert3005]

this should be enough

[robert3005]

I think we don't want to serialise this array, this is purely optimisation for list takes