Automate RowFn benchmark comparisons

[connortsui20]

Rationale for this change

Makes RowFn performance comparisons repeatable across revisions. The runner records enough build and machine state to reject stale benchmark artifacts.

• Progress towards: Epic: Row-oriented scalar functions #9128

What changes are included in this PR?

Adds separate build and measurement phases, reusable revision-specific target directories, package-grouped parallel builds, alternating process order, machine records, and paired median summaries. The primary profile uses one codegen unit, fat LTO, target-cpu=native, two warm runs, and seven measured pairs.

Focused executor benchmarks and script tests cover framework overhead, strict validity, result parsing, changing inventories, and ratio aggregation. Reused artifacts are validated against the revision, dirty-state digest, Rust and Cargo versions, build configuration, suite inventory, and executable hash.

What APIs are changed? Are there any user-facing changes?

There are no public Rust API changes. This PR adds the developer-facing scripts/benchmark-rowfn.sh command and its result format.

[codspeed-hq]

Merging this PR will improve performance by 13.64%

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

⚡ 1 improved benchmark
✅ 11 untouched benchmarks
⏩ 2129 skipped benchmarks¹

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	WallTime	words_gather_scalar[65536]	9.4 µs	8.2 µs	+13.64%

Tip

Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing ct/row-fn-benchmark-tools (b65f5d9) with ct/row-fn-spatial-predicates (12d920a)²}

Footnotes

1. 2129 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 ct/row-fn-spatial-predicates (7ce135f) during the generation of this report, so da8bb97 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[connortsui20]

Here are the local results that exercise the benchmark runner and its unchanged control suites.

The full-stack comparison used a develop baseline with benchmark-only backfills (1edd0fca) and the full RowFn stack (8ca9fc73). The machine was an AMD Ryzen 9 7950X running Linux. The build used rustc 1.97.1, LLVM 22.1.6, one CGU, fat LTO, and -C target-cpu=native.

The full comparison used two warm runs and seven alternating measured pairs. Each process used 100 samples with a 0.25–0.5 second measurement window on CPU 4. Negative changes are faster. The change is the median paired ratio, not the ratio of the two displayed medians.

This PR does not change these production paths. The control binaries still show layout-sensitive movement, including 14.72–17.21% regressions for list take/filter and a 15.66% improvement for per-row like. The focused cleanup comparison keeps RowFn executor cases within 0.93% and strict-validity cases within 1.64%.

RowFn executor cleanup comparison: 8 cases

This focused screen compared the pre-cleanup and post-cleanup framework with three measured pairs.

Benchmark	Before cleanup	After cleanup	Change
row_wrapping_add_nullable	139.400 µs	140.700 µs	+0.93%
row_checked_add_constant	33.110 µs	33.260 µs	+0.45%
row_checked_add_nullable	137.400 µs	138.200 µs	+0.29%
row_wrapping_add	137.100 µs	137.600 µs	+0.22%
row_wrapping_add_constant	31.780 µs	31.870 µs	+0.16%
row_sink_wrapping_add	136.300 µs	136.600 µs	+0.00%
handrolled_sink_wrapping_add	136.300 µs	135.200 µs	-0.15%
row_checked_add	138.000 µs	137.600 µs	-0.36%

Strict-validity cleanup comparison: 8 cases

These promoted cases used seven alternating measured pairs.

Benchmark	Before cleanup	After cleanup	Change
lazy_chain/1048576	1.317 ms	1.312 ms	+0.61%
eager_chain/1048576	1.304 ms	1.311 ms	+0.53%
eager/1048576	702.200 µs	711.100 µs	+0.14%
eager/65536	65.920 µs	65.760 µs	-0.24%
lazy_chain/65536	16.570 µs	16.580 µs	-0.30%
lazy/65536	5.419 µs	5.379 µs	-1.28%
lazy/1048576	616.000 µs	608.400 µs	-1.57%
eager_chain/65536	16.600 µs	16.160 µs	-1.64%

Like controls: 7 cases

Benchmark	Baseline	RowFn stack	Change
like_prefix	1.669 µs	1.889 µs	+13.18%
like_contains	12.700 µs	14.170 µs	+12.30%
ilike_contains	79.550 µs	80.800 µs	+1.47%
like_regex	44.580 µs	44.770 µs	+0.65%
like_exact	2.149 µs	2.139 µs	+0.00%
like_suffix	3.079 µs	3.059 µs	-0.65%
like_per_row_patterns	16.800 µs	14.160 µs	-15.66%

Take/filter controls: 17 cases

Benchmark	Baseline	RowFn stack	Change
take_filter_list_small_random_mask_random_indices/768/10	4.299 µs	5.039 µs	+17.21%
take_filter_list_slice_mask_random_indices/768/50	4.649 µs	5.379 µs	+16.13%
take_filter_list_slice_mask_sequential_indices/768/50	4.499 µs	5.179 µs	+15.96%
take_filter_list_nullable_random_mask_random_indices/768/50	5.009 µs	5.789 µs	+15.57%
take_filter_list_random_mask_random_indices/768/50	4.639 µs	5.349 µs	+15.52%
take_filter_list_small_uncached_random_mask_random_indices/768/10	4.769 µs	5.509 µs	+15.52%
take_filter_list_random_mask_sequential_indices/768/50	4.619 µs	5.259 µs	+14.72%
take_filter_primitive_small_random_mask_random_indices/16384/10	959.7 ns	949.7 ns	+1.93%
take_filter_primitive_slice_mask_random_indices/16384/1000	1.399 µs	1.429 µs	+1.43%
take_filter_primitive_slice_mask_sequential_indices/16384/1000	1.014 µs	1.019 µs	+0.93%
take_filter_primitive_random_mask_sequential_indices/16384/1000	1.359 µs	1.359 µs	+0.74%
take_filter_primitive_random_mask_random_indices/16384/1000	1.619 µs	1.639 µs	+0.61%
take_filter_primitive_small_uncached_random_mask_random_indices/16384/10	969.7 ns	954.7 ns	-0.53%
take_filter_primitive_large_random_mask_random_indices/(12500, 25000)	18.540 µs	18.460 µs	-0.59%
take_filter_primitive_nullable_slice_mask_random_indices/16384/1000	1.949 µs	1.919 µs	-1.03%
take_filter_primitive_nullable_random_mask_random_indices/16384/1000	2.019 µs	1.989 µs	-1.49%
take_filter_primitive_large_random_mask_random_indices/(2500, 25000)	11.090 µs	10.920 µs	-1.53%

VarBinView compaction controls: 8 cases

Benchmark	Baseline	RowFn stack	Change
compact_sliced/(16384, 10)	64.080 µs	70.030 µs	+9.29%
compact/(4096, 10)	49.960 µs	50.080 µs	+0.68%
compact/(16384, 10)	254.700 µs	254.300 µs	-0.16%
compact_sliced/(4096, 10)	16.250 µs	16.240 µs	-0.18%
compact/(16384, 90)	9.150 ns	8.993 ns	-1.72%
compact/(4096, 90)	8.681 ns	8.525 ns	-1.80%
compact_sliced/(4096, 90)	8.915 ns	8.525 ns	-1.80%
compact_sliced/(16384, 90)	9.540 ns	9.032 ns	-2.55%

[codspeed-hq]

Too many benchmarks in a single upload

The performance report could not be generated because there were too many benchmarks in a single upload to CodSpeed. We recommend sharding your benchmarks into smaller uploads, with max 1000 benchmarks per upload. See the documentation for more information.