[mhk197]

Summary

list_transform(list, lambda) applies a one-parameter lambda to every element of a List (in any encoding), keeping each list's length and validity.

Stacked on #10502.

Changes

• ListTransform's options are ListTransformOptions: the lambda as written (Lambda) in an expression, or bound to the element's dtype (BoundLambda) in a bound expression or an array. Its only child is the list.
• bind_options binds the lambda to the element's dtype when the node is bound, so execute only runs it. A FixedSizeList, or a lambda with more than one parameter, is rejected there.
• Execution first makes the lists exact: every null list is emptied, and list_from_list_view lays the lists out back to back with nothing before the first or after the last. Every element then belongs to exactly one valid list, so the lambda never sees a value nobody can read, such as leftovers under a null list, gaps in a list view or the rest of a slice.
• The lambda runs once over all the elements, and the result is a ListArray with the same offsets and validity around the new elements.
• The function is strict (a null list gives a null result), it can fail only if the lambda can, and it is not serializable yet.

list_transform(col("l"), Lambda::new(["x"], checked_add(var("x"), lit(1_i32)))?)
// vortex.list.transform($.l, (x) -> (@x + 1i32))

Testing

New tests cover binding the lambda with the node, null lists with and without hidden elements, sliced lists and list views, overlapping list views, nested lambdas three levels deep, re-rooting with replace, and dictionary inputs, both pushing an infallible transform into the values and skipping an unused value that a fallible body would fail on.

• cargo +nightly-2026-09-10 fmt -p vortex-array
• cargo clippy -p vortex-array --all-targets --all-features -- -D warnings
• cargo nextest run -p vortex-array (the full suite)
• cargo test --doc -p vortex-array -- lambda list_transform exprs::var

Follow-up

• Reading values from outside the lambda.
• FixedSizeList input, giving a FixedSizeList.
• Serialization.

[codspeed]

Merging this PR will regress 2 benchmarks

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

⚠️ 20 benchmarks spent significant time in system calls

System calls cannot be consistently instrumented, so they are not included in the measure, which understates the real cost. Please switch to the Walltime instrument to accurately measure system calls.

Measurement and system calls

• random_i128[0.01]
• chunked_varbinview_into_canonical[(10, 100)]
• compress_fsst[(500, 16, 8)]
• decompress[u32, (1000, 256)]
• chunked_dict_primitive_canonical_into[f64, (1000, 1000, 10)]
• test_repeated_scan[int_str_float]
• test_scan_to_arrow_array[int_str_float]
• test_scan_filter[int_str_float]
• test_scan[int_str_float]
• test_scan_filter[int_float]
• …and 10 more

ℹ️ 40 benchmarks have no flame graph

The flamegraph could not be generated because we failed to resolve the symbols in the profiling trace. This happens when we fail to harvest information about language frames.

• test_scan_filter[int]
• test_repeated_scan[int_str_float]
• test_repeated_scan_filter[int]
• test_scan_to_arrow_array[int_str_float]
• test_scan_filter[int_str_float]
• test_scan[int_str_float]
• test_scan_to_arrow_array[int]
• test_scan_filter_to_arrow_array[int_str]
• test_scan_filter[int_float]
• test_repeated_scan_filter[int_str]
• …and 30 more

⚠️ 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

⚡ 21 improved benchmarks
❌ 2 regressed benchmarks
✅ 2385 untouched benchmarks
⏩ 12 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	WallTime	mul_u64_nonnull_neon	20.4 µs	38.8 µs	-47.41%
❌	WallTime	words_gather_dispatch_neon[65536]	1.8 µs	2 µs	-10.24%
⚡	Simulation	fast_lt_out_of_range[16, 65536]	262.4 µs	69.6 µs	×3.8
⚡	Simulation	fast_eq_out_of_range[16, 65536]	258.8 µs	75.2 µs	×3.4
⚡	Simulation	fast_eq_out_of_range[4, 65536]	171.7 µs	75 µs	×2.3
⚡	Simulation	fast_lt_out_of_range[4, 65536]	157.4 µs	70.8 µs	×2.2
⚡	Simulation	new_bp_prim_test_between[i16, 32768]	217.5 µs	153.8 µs	+41.49%
⚡	Simulation	new_bp_prim_test_between[i16, 16384]	135.8 µs	103.8 µs	+30.79%
⚡	Simulation	new_bp_prim_test_between[i32, 32768]	222.5 µs	175.3 µs	+26.94%
⚡	Simulation	new_alp_prim_test_between[f32, 32768]	225.2 µs	177.9 µs	+26.56%
⚡	Simulation	new_bp_prim_test_between[i64, 32768]	240.5 µs	195.7 µs	+22.9%
⚡	Simulation	new_alp_prim_test_between[f64, 32768]	254.8 µs	209.9 µs	+21.37%
⚡ ℹ️	Simulation	test_scan_filter[int]	3.7 ms	3 ms	+21.34%
⚡	Simulation	chunked_opt_bool_canonical_into[(1000, 10)]	65.4 µs	54.4 µs	+20.13%
⚡	Simulation	new_bp_prim_test_between[i32, 16384]	138.4 µs	116.2 µs	+19.1%
⚡	WallTime	threshold_avx2[80]	3 µs	2.6 µs	+16.73%
⚡	Simulation	new_alp_prim_test_between[f32, 16384]	164.5 µs	141.9 µs	+15.96%
⚡	Simulation	new_bp_prim_test_between[i64, 16384]	149.1 µs	129.3 µs	+15.32%
⚡	Simulation	new_alp_prim_test_between[f64, 16384]	163.1 µs	143.2 µs	+13.86%
⚡ ⚠️	Simulation	random_i128[0.01]	6 µs	5.2 µs	+13.8%
...	...	...	...	...	...

ℹ️ 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 mk/list-transform-v3 (f687da3) with develop (3ded4dd)²}

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 mk/lambdas-v3 (8204f42) during the generation of this report, so develop (3ded4dd) was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩