Investigate benchmark regressions in Max, CompareTo, ReduceSignificance, Pow, and Divide since 2.0

[matt-edmondson]

Summary

Converting PreciseNumber to a value type in #70 cut allocation on every operation that returns a value, and made most operations faster. A same-machine comparison against 1.x also showed a few operations getting slower. The full 88-benchmark table is in this comment on #72.

Benchmark	Parameter	1.x	2.0	Change
Max	8 digits	2.991 ns	3.681 ns	+23%
Max	30 digits	2.985 ns	3.486 ns	+17%
Max	200 digits	2.301 ns	4.244 ns	+84%
CompareTo	8 digits	1.645 ns	1.906 ns	+16%
CompareTo	30 digits	1.650 ns	1.907 ns	+16%
CompareTo	200 digits	1.834 ns	1.923 ns	+5%
ReduceSignificance	8 digits	63.53 ns	75.44 ns	+19%
Pow	exponent 2	50.87 ns	57.33 ns	+13%
TryFormat	8 digits	36.96 ns	40.90 ns	+11%
Divide	8 digits	227.46 ns	237.26 ns	+4%
Divide	30 digits	381.25 ns	405.16 ns	+6%
Divide	200 digits	1,653.78 ns	1,684.76 ns	+2%

Nothing is broken, and the absolute differences are small, but Max at 200 digits nearly doubled.

Caveats

• This is a single run of the default BenchmarkDotNet job on a shared GitHub runner (Intel Xeon Platinum 8370C).
• "2.0" is main at the [major] Make PreciseNumber a value type #70 merge, before [patch] Fix conversion edge cases found in review #72. [patch] Fix conversion edge cases found in review #72 rewrote the rounding in ReduceSignificance and Round, so that row may have moved in either direction.

Suggested next steps

1. Rerun the comparison between 1.x (cd9a822) and current main, with both versions in one job. Separate workflow runs can land on different CPU generations, which made earlier numbers incomparable. Adding a baseline ref input to benchmarks.yml would make this repeatable. The one-off workflow used here checked out both refs side by side and passed --artifacts per class.
2. Profile whichever regressions reproduce. Places to start:
   • Max is x > y ? x : y, which now returns a copy of a 24-byte struct where 1.x returned a reference.
   • CompareTo delegates to the static Compare, so check that it still inlines.

[matt-edmondson]

Triage

Category: Improvement (investigation)
Priority: Low — consistent with the existing P4 label, which is already correct
Area: PreciseNumber — Max, CompareTo, ReduceSignificance, Pow, Divide

Low is the right call and the existing labels already say so: nothing is broken, correctness is unaffected, and the work is measurement before it is a fix. Worth keeping open rather than closing — a regression across five operations since 2.0 is a real signal, and performance debt that is never investigated is how a numerics library quietly stops being the fast option.

Scoping note. This is an investigation issue, not an implementation one, and it is worth resisting the pull to fix anything before the measurement is in. Five named operations is broad enough that the regressions may well have different causes — or, equally plausibly, one shared cause in a common path that all five route through, in which case the fix is far smaller than the issue's surface suggests. Finding out which of those two it is should be the deliverable, and closing it may mean filing narrower follow-ups rather than landing a change here.

Suggested assignment: unassigned is appropriate for now. This wants whoever knows the 2.0 change set, and it is a good candidate to pick up alongside other work in these code paths rather than scheduled on its own.

Duplicates: none found in this repo or elsewhere in the org.
Open PR covering this: none.

Suggested next step: establish the regression is real and attributable before spending time on any one operation — confirm the benchmark numbers reproduce on current main, then bisect the 2.0 range for the five operations together and see whether they share a commit. If they do, this is one fix; if they don't, split it.

---

Generated by Claude Code