[mhk197]

Summary

A lambda passed to list_transform can now read values from outside it, such as a column or a parameter of an enclosing lambda. The builder moves each such value out of the body into an extra input of the call and an extra parameter of the lambda. Every element of a row's list sees that row's value.

Stacked on #10503.

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

Changes

• Lambda::extract_captures turns each outside read ($, a path like $.s.a, another lambda's parameter, row_idx(), row_count()) into a new parameter. Lambda::new accepts them; binding still rejects them.
• list_transform(list, lambda) calls it, so the values are ordinary children: replace, field pruning and the scan's row_idx() see them.
• Execution repeats each value once per element of its list with take, using the index of the list that holds each element.
• A bound lambda is rebound instead of erroring when a rebuilt node's inputs change dtype (BoundLambda::rebind).
• With captures the function is not strict: a null captured value keeps its list valid.

Testing

• New tests: a captured column, null and constant captured values, captures in nested lambdas (a column, the outer parameter), rebinding, extract_captures naming, and a scan reading row_idx() inside a lambda (vortex-layout).
• Not run locally yet; CI only.

Follow-up

• Repeat captured values with RunEnd instead of take once RunEnd lives in vortex-array.

[codspeed]

Merging this PR will degrade performance by 17.63%

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

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

⚡ 3 improved benchmarks
❌ 8 regressed benchmarks
✅ 2397 untouched benchmarks
⏩ 12 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Walltime	filter_neon[8]	910 ns	1,903 ns	-52.18%
❌	Walltime	threshold_neon[8]	1.3 µs	2.6 µs	-49.54%
❌	Walltime	filter_neon[64]	1.8 µs	2.6 µs	-32.46%
❌	Walltime	threshold_neon[64]	2.6 µs	3.6 µs	-28.94%
❌	Walltime	filter_neon[80]	2.6 µs	3.4 µs	-23.49%
❌	Walltime	threshold_neon[80]	3.6 µs	4.6 µs	-22.99%
❌	CPU Simulation	test_repeated_scan_scalar_at[int_str_float]	484 µs	595.7 µs	-18.74%
❌	CPU Simulation	test_scan_filter[int]	3 ms	3.4 ms	-11.34%
⚡	Walltime	mul_u64_nonnull_neon	39.2 µs	20.8 µs	+88.39%
⚡	Walltime	bitpack_blocked_compress_avx2	7.6 µs	6.7 µs	+13.5%
⚡	CPU Simulation	random_i8[0.01]	116.1 µs	103 µs	+12.69%

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-captures (12459ae) with mk/list-transform-v3 (a4e9fe2)}

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