Tracking slowdown introduced sometime before v5.2.2 release was made #1180

While performing timing studies for the low-p tracking upgrade, we stumbled upon a slowdown in the code introduced sometime between the version being used for MC production (~June 2026) and when v5.2.2 was released (~early August 2026).

The timing per track and event is summarized:

Timing results (ap_14596, 200 MeV, overlay_to_recon jobs, n=10 unless noted)
-----------------------------------------------------------------------------
Build                                        time/event (ms)   time/track (ms)
oldold (pre-regression, n=200)                102.5 +/- 9.3      36.1 +/- 3.0
oldold_ec09f1bf5 (pre-regression, n=10)        79.0 +/- 7.8      28.2 +/- 2.7
v5pt2 (current production, regressed, n=10)   217.0 +/- 49.3     77.3 +/- 17.0
static-final debug (attempt 2 / fix, n=10)     87.4 +/- 10.5     31.1 +/- 3.5
-----------------------------------------------------------------------------

The "static-final debug" is the fixed version. The cause of the slowdown in v5.2 was commit 44ee666 changed the debug field in
KalmanPatRecHPS.java from a compile-time constant

private static final boolean debug = false;

to a runtime-armed instance field

private boolean debug = false;
...
debug = (kPar.debugEvent != -1 && eventNumber == kPar.debugEvent);

so that Kalman tracing could be armed for a single event number via
KalmanParams.debugEvent, without recompiling.

Because debug is no longer a compile-time constant, javac can no longer
dead-code-eliminate the ~150 "if (debug) ..." blocks scattered through
kalmanPatRec(). This bloated the method's compiled bytecode from ~8,000
bytes to ~15,387 bytes -- past HotSpot's HugeMethodLimit (default 8,000
bytes) -- which permanently disqualifies the method from C2 JIT
compilation. The method has run interpreted-only ever since.

The fix is to change this back to static final....

The plot below shows a complicated run-down of the different versions and samples tested.