Use AI to analyze performance bottlenecks

[jnspitale]

The focus has always been to handle operations on large arrays as quickly as possible. I have learned a few things since I first wrote Polymath. For example, there are places where I check for a zero in a denominator before I divide, where it would be faster to divide and catch the DivideByZero exception. This gets tricky though because sometimes this shows up as a warning, not an error, and other times the array silently fills with infs or NaNs instead. (I don't want to see infs or NaNs in the data arrays; that's what the masks are for.) I bet there are also many other places where performance of the low-level code could be improved.


[jnspitale]

Addressed by #17. The performance analysis this issue asked for was done and written up in critiques/2026-08-10-performance-critique.md — a profiled bottleneck study with each fix measured before and after. Outcome against the previous main: median 4.29x, geometric mean 3.71x across 41 operations, with the two slower operations documented as deliberate trades.

On the divide-by-zero example specifically: the critique found the cost was not the zero check itself but the mask_where(..., replace=...) guard path behind it, which copied the whole object regardless of how few items matched (a / b: 8.6 µs with no zeros, 89.5 µs with ten). The fix kept the check-then-mask pattern but made it fast — mask_where_eq went from 52.4 to 4.5 µs, and Scalar / from 76.7 to 8.1 µs (9.4x). Divide-and-catch turned out not to apply: NumPy array division by zero warns or fills with infs rather than raising, and the zeros have to be located anyway to set the mask and zero the derivatives there.

Remaining lower-priority items are recorded in the critique (§5) for any future round.