Materialize list offsets once in list_view_from_list

[connortsui20]

Rationale for this change

list_view_from_list executed the lazy offsets that reset_offsets produces inside build_sizes_from_offsets, dropped that result, and then sliced the still-lazy handle into the view, so the subtraction kernel ran a second time when a consumer canonicalized the offsets child. Extracted from investigating #9255, where the CodSpeed report showed ~35% improvements on the take_filter_list benchmarks. This fix alone recovers about half of that locally (12.6µs to 10.1µs median on take_filter_list_random_mask_sequential_indices[768, 50]); the remainder is the cost of building and executing the lazy subtraction node at all.

What changes are included in this PR?

list_view_from_list executes the offsets to a PrimitiveArray once at the top, computes sizes from that array, and slices it zero-copy for the view's offsets. build_sizes_from_offsets now takes the materialized offsets instead of executing its own copy. Also adds a regression test that list-to-listview conversion resets nonzero leading offsets.

[codspeed-hq]

Merging this PR will regress 6 benchmarks

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 18 improved benchmarks
❌ 6 regressed benchmarks
✅ 1920 untouched benchmarks
⏩ 85 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	cold_misaligned[(64, 256)]	4.4 ms	5.2 ms	-16.31%
❌	Simulation	take[small_m/shuffled/primitive/nonnull/chunks=1024/indices=1000]	5.6 ms	6.4 ms	-13.03%
❌	Simulation	take[small_m/shuffled/primitive/nonnull/chunks=1024/indices=256]	2.1 ms	2.4 ms	-12.69%
❌	Simulation	take[small_m/shuffled/primitive/nonnull/chunks=16384/indices=1000]	9.6 ms	10.8 ms	-11.84%
❌	Simulation	take[core/shuffled/primitive/nonnull/chunks=1024/indices=10000]	13.6 ms	15.3 ms	-10.97%
❌	Simulation	compress_fsst[(1000, 64, 8)]	1 ms	1.1 ms	-10.39%
⚡	Simulation	multipolygon_random_nulls	942.4 µs	816 µs	+15.49%
⚡	Simulation	take_filter_list_slice_mask_random_indices[768, 50]	240.9 µs	211.2 µs	+14.08%
⚡	Simulation	take_filter_list_random_mask_sequential_indices[768, 50]	236.8 µs	208.7 µs	+13.46%
⚡	Simulation	take_filter_list_slice_mask_random_indices[256, 50]	239.1 µs	210.9 µs	+13.39%
⚡	Simulation	take_filter_list_random_mask_sequential_indices[256, 50]	241.8 µs	213.3 µs	+13.34%
⚡	Simulation	multipolygon_non_nullable	1.2 ms	1.1 ms	+12.77%
⚡	Simulation	take_filter_list_slice_mask_sequential_indices[256, 50]	237.4 µs	210.6 µs	+12.7%
⚡	Simulation	multipolygon_mixed_validity	1.2 ms	1.1 ms	+12.36%
⚡	Simulation	take_filter_list_small_uncached_random_mask_random_indices[256, 10]	233.7 µs	208.1 µs	+12.35%
⚡	Simulation	take_filter_list_small_uncached_random_mask_random_indices[768, 10]	242.2 µs	215.8 µs	+12.25%
⚡	Simulation	take_filter_list_small_random_mask_random_indices[256, 10]	232.8 µs	207.6 µs	+12.15%
⚡	Simulation	take_filter_list_random_mask_random_indices[768, 50]	256.1 µs	228.3 µs	+12.14%
⚡	Simulation	take_filter_list_slice_mask_sequential_indices[768, 50]	236.8 µs	211.2 µs	+12.11%
⚡	Simulation	take_filter_list_random_mask_random_indices[256, 50]	245.9 µs	220.3 µs	+11.61%
...	...	...	...	...	...

ℹ️ 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 claude/list-offsets-optimization-9btwil (d97e53e) with develop (66d096b)}

Footnotes

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

[connortsui20]

This makes me sad.

I believe that this is mostly because dispatch completely ruins optimizations that the compiler would otherwise be able to make.

[robert3005]

The question worth asking is are you optimising the benchmark or are you optimising some real thing. I don't think it's anything to do with what you're saying. It's that comparatively to a small list the dispatch is the bigger part. Basically I don't think this is an optimisation in practice

[connortsui20]

@robert3005 there is a problem here either way. If this is a real optimization, then this should be fixed. If this is not a real optimization, then we really need to reconsider if these microbenchmarks are useful to us at all. How can we make any decision if we cannot trust our own benchmarks?

[connortsui20]

Also @robert3005, it seems like the slowdown is actually because we give adjusted_offsets as a lazy array to ListArray::new_unchecked, and then when it becomes a list view later it does a bunch of extra work it didnt need to.