Add scalar function performance baselines

[connortsui20]

Summary

Tracking Issue: #9128

Adds stable scalar function performance baselines for byte_length, l2_norm, normalized, inner_product, cosine_similarity, GeoContains, and GeoIntersects.

The benchmark sizes are all comfortably above the roughly 146-instruction Divan harness floor from #9011. Each benchmark binary also uses vendored mimalloc, since scalar function execution allocates its output inside the timed trace and glibc differences between runner images caused the flakes fixed in #8861.

Why

Codspeed can only compare a later implementation change when the same benchmark name already exists on develop, so these baselines need to land before the RowFn things I want to make. And these are pretty cheap, might as well add them.

[codspeed-hq]

Merging this PR will not alter performance

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

✅ 1885 untouched benchmarks
🆕 74 new benchmarks
⏩ 1 skipped benchmark¹

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
🆕	Simulation	inline[4096]	N/A	141.1 µs	N/A
🆕	Simulation	inline[65536]	N/A	1.8 ms	N/A
🆕	Simulation	nullable_out_of_line[4096]	N/A	156.8 µs	N/A
🆕	Simulation	nullable_out_of_line[65536]	N/A	1.8 ms	N/A
🆕	Simulation	out_of_line[4096]	N/A	141.7 µs	N/A
🆕	Simulation	out_of_line[65536]	N/A	1.8 ms	N/A
🆕	Simulation	add_i32_nonnull	N/A	915.7 µs	N/A
🆕	Simulation	add_i64_constant	N/A	1.2 ms	N/A
🆕	Simulation	add_u32_nonnull	N/A	916.7 µs	N/A
🆕	Simulation	nullable_out_of_line_90pct[4096]	N/A	169.6 µs	N/A
🆕	Simulation	nullable_out_of_line_90pct[65536]	N/A	1.8 ms	N/A
🆕	Simulation	like_per_row_distinct_patterns	N/A	628.3 µs	N/A
🆕	Simulation	like_per_row_repeated_patterns	N/A	173.1 µs	N/A
🆕	Simulation	column_x_column_points	N/A	720.4 µs	N/A
🆕	Simulation	column_x_column_polygons	N/A	1.1 ms	N/A
🆕	Simulation	constant_x_nullable_points	N/A	1.6 ms	N/A
🆕	Simulation	constant_x_nullable_polygons_disjoint	N/A	1.8 ms	N/A
🆕	Simulation	constant_x_points	N/A	1.4 ms	N/A
🆕	Simulation	constant_x_polygons_disjoint	N/A	1.6 ms	N/A
🆕	Simulation	column_x_column_polygons	N/A	1 ms	N/A
...	...	...	...	...	...

ℹ️ Only the first 20 benchmarks are displayed. Go to the app to view all benchmarks.

---

_{Comparing ct/scalar-fn-baselines (210a2c8) with ct/l2-denorm-encoding (a562e60)}

Footnotes

1. 1 benchmark was skipped, so the baseline result was used instead. If it was deleted from the codebase, click here and archive it to remove it from the performance reports. ↩

[joseph-isaacs]

This benchmark has a too long runtime

[joseph-isaacs]

Still too long

[connortsui20]

@joseph-isaacs what is too long? which one?

https://github.com/vortex-data/vortex/blob/develop/docs/developer-guide/benchmarking.md has nothing about benchmarks being too long, can you make a PR there?

[joseph-isaacs]

column_x_column_polygons | N/A | 23.8 ms

[connortsui20]

@joseph-isaacs this is unhelpful. There are other benchmarks here that are longer too (i.e. 123ms). Is there some limit here that is undocumented? Why is it bad for microbenchmarks to be "long" in the first place if we're still able to get useful info out of it?

[robert3005]

They’re not very micro benchmarks with that runtime. I think in aggregate there’s ~30 non compliant benchmarks. This numbers is an arbitrary threshold we keep to stop them from decaying over time

[joseph-isaacs]

I usually think under 1 ms is a good target unless there is a very good reason to go above this.

If we go above this two things happen:

• the time benchmarks take to run just keep increase at a faster rate
• codspeed gets upset

[connortsui20]

@joseph-isaacs everything is sub ms now

[HarukiMoriarty]

The geo part micro benchmark looks good to me!