[connortsui20]

Tracking Issue: #9128

Summary

Prepares the RowFn batch types for #10675 without changing how a batch executes. Execution still plans with one dispatch and executes with a second one, as on develop.

This is a purely mechanical change that should help with function call and access overhead.

Changes

• Adds InputElement::decode_ref, which decodes a borrowed input. The default clones the array for decode. Native primitives share their canonical buffer without executing the array.
• Inspects the inputs once in BatchProbe: row counts, batch-constant classification, null literals, and the conjoined validity. Execution reads the probe instead of scanning the inputs again. A null literal skips the validity conjunction, because every row is null either way.
• Keeps the columns in BatchInputs, which borrows them when the caller holds them as one slice. RowFnExecutionArgs borrows the batch and the dtypes instead of owning copies. execute_row_inputs runs over any RowInputs, and execute_rows adapts a general ExecutionArgs to it.
• Skips the all-valid check in finalize_kernel_output when the output is not nullable, and marks the CachedId read #[inline].

Adds five regression cases covering invalid payloads, null short circuits, lazy division, device-backed validity, and device-backed primitive input. They pass on the existing execution flow, so #10675 shows that its single-dispatch path keeps that behavior.

[codspeed]

Merging this PR will degrade performance by 9.47%

3 warnings

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

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

⚡ 2 improved benchmarks
❌ 4 regressed benchmarks
✅ 2298 untouched benchmarks

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Walltime	threshold_neon[64]	2.6 µs	4.5 µs	-42.32%
❌	CPU Simulation	filter_powerlaw_by_random[10000]	813.5 ns	1,221 ns	-33.38%
❌	CPU Simulation	missing_stats[16]	67.9 µs	85.4 µs	-20.44%
❌	Walltime	threshold_neon[80]	3.5 µs	4.1 µs	-14.56%
⚡	Walltime	mul_u64_nonnull_neon	39.2 µs	20.6 µs	+89.76%
⚡	Walltime	starts_with_neon[8, VarBin]	45.5 µs	41 µs	+11.05%

Tip

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

---

_{Comparing ct/row-fn-cleanup/batch-inspection (0ddfefa) with develop (f04a28c)}

[connortsui20]

im pretty sure the mul_u64_nonnull_neon is a flake, it always changes