[connortsui20]

Tracking Issue: #10701

Based on develop, including the merged #10946. #11004 builds on it. No release gate.

Summary

Comparisons, bounds checks and fills otherwise widen every decimal value before doing their work. The child's precision already bounds its values, so these operations can often stay narrow or answer a comparison without reading the buffer.

Changes

Constants that fit use the child dtype, and constants outside its precision answer comparisons from the range bound. Two decimal children compare at their larger precision. Dtype matches select the compatible types, then integer and decimal kernels share casts and execution. A decimal fill outside the child precision falls back to canonical execution. These shortcuts rely on the documented requirement that every valid value fits the child precision.

Shares the canonical comparison assertion and decimal fixtures, removes duplicate scalar precision coverage, and reduces the new decimal test cases from 193 to 99. Keeps the four paired benchmark cases for in-range comparisons and the out-of-range shortcut.

Historical local benchmark results

These retained measurements predate this style pass and rebase. They do not measure the current head.

cargo bench -p vortex-array --bench widen_decimal, Apple M4, medians. The numbers were measured at the top of this stack before the split, so they cover the whole stack, not this layer alone. The baseline is the canonical input, and the candidate is the same values as a Widen (child precision 5 under precision 10, 9 under 18, and 18 under 38). CodSpeed on this PR measures the layer itself.

bench	p10 canonical	p10 Widen	p18 canonical	p18 Widen	p38 canonical	p38 Widen
compare_constant	4.166 µs	5.041 µs	4.124 µs	5.041 µs	10.7 µs	4.207 µs
compare_constant_out_of_range	3.791 µs	374.5 ns	3.79 µs	374.5 ns	9.874 µs	397.9 ns

API Changes

None.

Validation

Source review and downstream rebase range-diffs. No local tests, builds, formatting, linting, or benchmarks were run, per repository instructions.

[codspeed]

Merging this PR will degrade performance by 12.91%

1 warning

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

❌ 4 regressed benchmarks
✅ 1878 untouched benchmarks
⏩ 469 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	CPU Simulation	bench_compare_varbin[(50000, 2)]	133.6 µs	162.3 µs	-17.71%
❌	CPU Simulation	bench_compare_sliced_dict_varbinview[(1000, 10000)]	79.7 µs	90.5 µs	-11.94%
❌	CPU Simulation	bench_compare_sliced_dict_varbinview[(9999, 10000)]	206.6 µs	233.4 µs	-11.47%
❌	Walltime	add_constant_shapes_neon[(32768, PerRowNullableConstant)]	14.9 µs	16.6 µs	-10.32%

Tip

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

---

_{Comparing ct/decimal-widen-compare (b991aa6) with develop (d166762)}

Footnotes

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

[joseph-isaacs]

do we actually need more benchmarks. You could unit test the pushdown?

[joseph-isaacs]

Code looks good.

I think we need less benchmark, tighter test.

Maybe assert of the reduction of a compare + widen

[connortsui20]

I removed the benchmarks