[connortsui20]

Summary

• Tracking Issue: Epic: Row-oriented scalar functions #9128
• Supersedes Attach RowFn validity during Boolean output construction #10674
• Related discussion: Attach RowFn validity directly to canonical output #9694
• Independent float32 candidate: Pack float32 comparison results into bitmap words #10741

Attaches input validity directly when a RowFn kernel already returns canonical output, avoiding an extra lazy mask execution. Reuses the existing canonical-validity helper instead of passing validity through the visitor and collector interfaces.

Changes

Keeps kernel-output validation before masking, then retains output relabeling and outer-nullability handling. Non-canonical output uses the existing lazy mask fallback. This PR is independent of float32 packing and the broader RowFn migration.

Draft pending design review and fresh isolated benchmarks on this head. This revisits the abstraction concern raised in #9694. The measurements support exploring the smaller change, but do not resolve that concern or establish a regression-free result.

Saved benchmark evidence and validation

The isolated validity snapshot b1961452ea3505d4e2588e34b14c20ea177ed175 was compared with frozen develop at a1693389301e446eec41373cb274d98a303d3ca0. Measurements used Rust 1.99.1 / LLVM 23.1.1, 16 CGUs, no LTO, CPU 2, and 21 balanced paired blocks on Graviton3 C7g and Sapphire Rapids C7i. This was native wall time, not CodSpeed simulation.

For nullable u64 addition with 64 rows and a right-hand constant, median paired time ratios were:

Target	Candidate / baseline time	95% paired bootstrap interval
NEON	0.798	0.796–0.802
AVX2	0.850	0.846–0.852
AVX-512	0.846	0.844–0.855

The isolated snapshot also had flagged regressions outside that case: roughly 3.4% slower ARM u64 multiply and up to 4.2% slower AVX2 byte comparisons. No regressions crossed the 3% flag on AVX-512 in that run. These movements remain part of the review, even where unchanged code is sensitive to compiler context or binary layout.

A separate combined packing/validity candidate at 8d8ef8151454bbc73e1cd0b236567542a1401cbe, based on d834a11faa79370b4d2e0bbcc73195f451a8a212, retained the small-batch gain but regressed nullable u64 add by about 12% at 8,192 rows and 18% at 32,768 rows on AVX2. Profiling found a byte-identical retry hot loop with essentially unchanged instructions per operation and more cycles. The precise placement-sensitive mechanism remains unresolved. That combined result does not isolate this PR.

The combined candidate passed 225 RowFn tests and 232 binary-function tests on that newer base, including output validation, allocator, and deferred-error coverage. Separate native probes checked null-row arithmetic errors and comparison edge cases. The changed file passed the pinned formatter. These are saved checks, not fresh validation of this individual PR.

This PR is rebased onto c750fbd80882f78efd6a2703bc0f3e17f1aca9f9. The patch is unchanged by the rebase. Tests and benchmarks were not rerun after it.

[codspeed]

Merging this PR will degrade performance by 4.67%

4 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

⚠️ Unable to measure the execution of 2 benchmarks

These benchmarks measured no execution time, so their results are not comparable and count as unchanged. This usually happens when the compiler removes the code under test.

Prevent compiler optimizations

See affected benchmarks

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

⚡ 6 improved benchmarks
❌ 6 regressed benchmarks
✅ 2396 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.5 µs	40.4 µs	-49.2%
❌	CPU Simulation	filter_powerlaw_by_mostly_false[250000]	138.7 µs	158.7 µs	-12.62%
❌	CPU Simulation	filter_random_by_mostly_false[250000]	163.2 µs	183.7 µs	-11.19%
❌	CPU Simulation	filter_powerlaw_by_power_law[250000]	166.2 µs	185.7 µs	-10.54%
❌	CPU Simulation	filter_random_by_power_law[250000]	166.1 µs	185.5 µs	-10.48%
❌	CPU Simulation	density_sweep_dense_runs[0.001]	53.6 µs	59.7 µs	-10.32%
⚡	CPU Simulation	test_scan_filter_to_arrow_array[int_float]	4.1 ms	3.5 ms	+15.84%
⚡	CPU Simulation	test_repeated_scan_filter[int_float]	3.9 ms	3.4 ms	+12.15%
⚡	Walltime	starts_with_avx2[64, VarBin]	62.7 µs	56 µs	+11.84%
⚡	CPU Simulation	test_repeated_scan_filter[int]	2.7 ms	2.4 ms	+11.38%
⚡	CPU Simulation	test_scan_filter_to_arrow_array[int]	2.8 ms	2.5 ms	+11.05%
⚡	Walltime	add_constant_shapes_neon[(32768, PerRowConstant)]	15.9 µs	14.3 µs	+10.78%

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/canonical-validity (c0f37b3) with develop (d02df89)}

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