Investigate CI slowdown since Python 3.12 bump

[utensil]

After #564 bumped CI from Python 3.8/3.9/3.10 to 3.10/3.11/3.12, total CI runtime increased by ~40–50 seconds.

Before #564: ~280–326 s (median ~320 s)
After #564: ~352–371 s (median ~360 s)

The cause is that Python 3.12 is the slowest job (~6 min) while 3.10 and 3.11 finish in ~4 min. Since jobs run in parallel, 3.12 sets the ceiling. Previously 3.10 was the ceiling at ~4 min.

Possible investigations:

• Why is the 3.12 job ~2 min slower? Is it test execution time, dependency install, or runner warmup?
• Are there specific tests or notebooks that are slower under 3.12?
• Could caching be improved to reduce install time?

[utiberious]

LaTeX.ipynb::Cell 2 (derivatives_in_prolate_spheroidal_coordinates) dominates CI time on all versions — ~700–1500 s depending on runner. The file already has a sibling commented out with # FIXME This takes ~600 seconds.

This is a separate issue from the 3.12 differential though (see next comment). The 3.12 slowdown is systemic, not caused by this one cell.

[utiberious]

Python 3.12 is consistently ~2× slower than 3.11 across all heavy tests (same CI run):

Test	3.11	3.12
test_check_generalized_BAC_CAB_formulas	11s	23s
test_reciprocal_blades[generic]	6s	11s
test_proj	3s	6s
test_lt::test_basic	3s	6s
LaTeX.ipynb::Cell 2	727s	1490s

This is systemic — not one slow test. The LaTeX.ipynb cell is a separate pre-existing problem that gets amplified by the 3.12 slowdown.

The original numbers in the issue description (~320s → ~360s) don't match current data — those were likely measured before the heavier notebook tests were part of the suite.

[utiberious]

Two upstream issues likely explain the ~2× slowdown:

• python/cpython issue 109049 — dict operation regression in 3.12 vs 3.11. SymPy uses dicts for all assumption caching and memoization, so every expression node is affected.
• python/cpython issue 124567 — Python 3.12's incremental GC slows Sphinx (same pattern: building and discarding large object graphs). SymPy expression trees work the same way.

Both are closed in CPython but the fixes may not fully cover SymPy 1.12's usage patterns.

Quickest thing to try: run the test suite with SymPy 1.13 on 3.12 and see if the gap narrows.

[utiberious]

Corrected analysis: two separate problems

After pulling per-test timing from CI logs across pre- and post-SymPy-bump runs, the picture is clearer.

Problem 1 — Python 3.12 unit test regression (original issue)

Confirmed from the Python 3.12 bump run (SymPy 1.12, 2026-04-01):

Test	3.10	3.11	3.12
test_check_generalized_BAC_CAB_formulas	14s	13s	26s
test_reciprocal_blades[generic]	7s	7s	11s
test_proj	4s	4s	7s
test_lt::test_basic	3s	3s	6s
LaTeX.ipynb::Cell 2	89s	88s	80s
Total suite	3:32	3:32	4:46

Python 3.12 is ~2x slower for unit tests. This is the CPython 3.12 dict/GC regression (cpython #109049). LaTeX.ipynb::Cell 2 was fast on all versions at this point (~80-89s).

Problem 2 — SymPy 1.13 regression for LaTeX.ipynb::Cell 2

The CI-time explosion (minutes → tens of minutes) happened at the SymPy 1.13 bump (#570), not at the Python 3.12 bump. First post-bump run (2026-04-02T07:02):

Version	LaTeX.ipynb::Cell 2	Change
3.11	1464s (was 88s)	17x slower
3.12	887s (was 80s)	11x slower

Latest run (2026-04-03):

Version	LaTeX.ipynb::Cell 2	Total suite
3.11	1838s	32:07
3.12	893s	16:32

This is a SymPy 1.13 regression for the derivatives_in_prolate_spheroidal_coordinates computation in LaTeX.ipynb::Cell 2. It is not a Python version problem — it hits 3.11 harder than 3.12.

Summary

• The original Investigate CI slowdown since Python 3.12 bump #576 (3.12 unit tests 2x slower) is real but minor — it added ~1 min to CI
• The dominant slowdown is a SymPy 1.13 regression for one notebook cell, which should be reported upstream
• Possible mitigations: mark the cell as slow/skip in nbval, or bisect SymPy 1.12→1.13 to find the offending commit

[utiberious]

Root cause analysis

galgebra side

metric.normalize_metric (called when norm=True) calls Simp.apply which defaults to simplify — the full kitchen-sink simplification function. For prolate spheroidal coordinates this triggers 70 simplify calls on expressions of the form sin(eta)*cosh(xi) / sqrt(sin(eta)^2 + sinh(xi)^2). Each call runs trigsimp which calls futrig, which applies "fu rules" (trig identity transformations) in 1000+ iterations per call.

With SymPy 1.12, total cost is ~5s for Ga.build. Expensive but manageable.

SymPy 1.13 side

SymPy pull request 26390 ("allow TR3 and TR4 to work with unevaluated expr", merged 2024-03-23) added a .replace() traversal inside TR3 in sympy/simplify/fu.py:

rv = rv.replace(
    lambda x: isinstance(x, TrigonometricFunction),
    lambda x: x.replace(lambda n: n.is_number and n.is_Mul, lambda n: n.func(*n.args)))

futrig (used by trigsimp, used by simplify) internally converts hyperbolic functions to trig via hyper_as_trig, so after that conversion sinh and cosh instances become TrigonometricFunction instances too. The new TR3 .replace() now traverses ALL of them on every one of the 1000+ _futrig iterations, on every one of the 70 simplify calls — scaling very badly for expressions with many mixed trig/hyperbolic terms.

Summary

The root cause is split:

• galgebra: using simplify (expensive) instead of something lighter in normalize_metric — a pre-existing design choice that became catastrophic with SymPy 1.13
• SymPy 1.13: TR3 change added a .replace() traversal that scales poorly for mixed trig+hyperbolic expressions (via the hyper_as_trig conversion that futrig does internally)

Possible mitigations

1. galgebra (immediate): change Simp.modes in normalize_metric to something lighter — e.g. trigsimp alone, or a custom simplifier that avoids calling futrig on these surd-denominator expressions
2. SymPy upstream: report the performance regression caused by sympy/sympy pull request 26390 for mixed trig/hyperbolic expressions
3. workaround (short-term): skip the slow test cell or mark it @pytest.mark.slow until a fix lands

[utiberious]

Fix options

The root cause is Simp.apply calling simplify (via Simp.modes = [simplify]) ~70 times in normalize_metric for prolate spheroidal coordinates. simplify routes through trigsimp → futrig → _futrig, which in SymPy 1.13 became very slow for mixed trig+hyperbolic expressions due to the TR3 .replace() traversal added in upstream pull request 26390.

Three options to fix this in galgebra/metric.py:

Option A — trigsimp with explicit method='matching'
Use pattern matching instead of the fu-rules path. Avoids futrig and the slow TR3 traversal entirely.

from sympy import trigsimp
Simp.modes = [lambda e: trigsimp(e, method='matching')]

Risk: pattern matching may not reduce sinh^2 + cosh^2 style metric terms as much.

Option B — trigsimp (default)
Same idea but relying on whichever default SymPy uses. In SymPy 1.13 the default for trigsimp is 'matching', so this should be equivalent to A.

Simp.modes = [trigsimp]

Option C — cancel (algebraic only)
Skip trig transforms entirely; just cancel common factors. Extremely fast. Risk: metric components may remain in expanded form, slowing down downstream computations.

from sympy import cancel
Simp.modes = [cancel]

Testing all three against the offending notebook cell (derivatives_in_prolate_spheroidal_coordinates) now.

[utiberious]

Performance test results

Tested all three options against derivatives_in_prolate_spheroidal_coordinates (the offending cell). Baseline with simplify: ~1800s on Python 3.11.

Option	Simp.modes change	Ga.build time	grad*f time	Metric correct
A	[trigsimp]	1.95s	0.00s	yes
B	[lambda e: trigsimp(e, method='matching')]	1.92s	0.00s	yes
C	[cancel]	0.33s	0.00s	yes

All three produce the same simplified metric: e_norm[0] = sqrt(sin(eta)**2 + sinh(xi)**2)*Abs(a), g[0,0] = 1. The trig identity reduction (sinh^2 + cosh^2 = 1) happens in square_root_of_expr via its own trigsimp call, not in Simp.apply — so the choice of Simp.modes does not affect output quality here.

Recommendation: Option A — change Simp.modes = [simplify] to Simp.modes = [trigsimp]. It is the semantically appropriate replacement (trig/hyperbolic expressions is exactly what this path handles), produces identical output, and reduces Ga.build from ~1800s to ~2s for prolate spheroidal coordinates.