Add TimerOutputs instrumentation to ground-state algorithms

[lkdvos]

This adds optional per-section timing to VUMPS, DMRG / DMRG2, IDMRG / IDMRG2, and GradientGrassmann, using TimerOutputs.jl. Each algorithm allocates its own TimerOutput, sub-sections mirror the natural phases (eigsolves, orth steps, env transfers, gauge solver, ...), and the summary is emitted via @infov 4 so it is gated by the existing verbosity setting.

The section structures end up looking like:

VUMPS                        IDMRG / IDMRG2                 DMRG / DMRG2                 GradientGrassmann
├── localupdate              ├── localupdate                ├── sweep                    ├── fg
│   ├── AC_eigsolve          │   ├── AC_eigsolve  /         │   ├── AC_eigsolve  /       │   ├── envs
│   └── C_eigsolve           │   │   AC2_eigsolve           │   │   AC2_eigsolve         │   │   ├── left_envs
├── gauge                    │   ├── ortho_step /           │   ├── svd_trunc (DMRG2)    │   │   └── right_envs
│   ├── gauge_eigsolve       │   │   svd_trunc              │   └── AC_update            │   ├── expval
│   └── gauge_orth           │   └── transfer_env           └── finalize                 │   └── gradient
├── envs                                                                                  ├── retract
│   ├── left_envs                                                                         ├── transport!
│   └── right_envs                                                                        └── precondition
├── finalize
└── calc_galerkin

A representative VUMPS run with verbosity=4 on a 3-site Ising chain:

Section            ncalls     time    %tot     avg     alloc    %tot      avg
─────────────────────────────────────────────────────────────────────────────
localupdate             6    262ms   64.8%  43.7ms   44.4MiB   46.1%  7.39MiB
  AC_eigsolve          18    271ms   67.0%  15.0ms   78.7MiB   81.7%  4.37MiB
  C_eigsolve           18    147ms   36.4%  8.17ms   35.0MiB   36.4%  1.95MiB
envs                    6   72.9ms   18.1%  12.2ms   33.7MiB   35.0%  5.62MiB
  left_envs             6   71.6ms   17.7%  11.9ms   33.6MiB   34.9%  5.60MiB
  right_envs            6   57.5ms   14.2%  9.58ms   29.5MiB   30.6%  4.92MiB
gauge                   6   62.3ms   15.4%  10.4ms   15.4MiB   16.0%  2.57MiB
  gauge_eigsolve       73   33.1ms    8.2%   453μs   9.39MiB    9.8%   132KiB
  gauge_orth           73   27.5ms    6.8%   377μs   5.60MiB    5.8%  78.5KiB
calc_galerkin           6   6.90ms    1.7%  1.15ms   2.78MiB    2.9%   474KiB
finalize                6    730ns    0.0%   122ns     0.00B    0.0%    0.00B

Note that inner sections can show %tot > 100% relative to their parent (AC_eigsolve's 67% vs localupdate's 64.8%) — that's because tforeach runs sites concurrently, so per-call wall-time summed across threads exceeds the parent's wall-clock.

Control is via the existing verbosity:

find_groundstate(ψ, H, VUMPS(; verbosity = 4))   # timer enabled and printed (= VERBOSE_ALL)
find_groundstate(ψ, H, VUMPS(; verbosity = 3))   # default — disable_timer! makes @timeit a no-op

Wherever a timed section sits inside a tforeach / @spawn (VUMPS site loop, env compute, multiline rows), each task gets its own TimerOutput and we merge! after the synchronization point. The merge target is computed dynamically from timeroutput.timer_stack, so nested wrappers like fg → envs → left_envs work without hardcoding tree paths.

[codecov]

Codecov Report

❌ Patch coverage is 91.81034% with 19 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/algorithms/groundstate/vumps.jl	68.57%	11 Missing ⚠️
src/algorithms/grassmann.jl	72.72%	3 Missing ⚠️
src/algorithms/groundstate/dmrg.jl	94.00%	3 Missing ⚠️
src/states/ortho.jl	91.30%	2 Missing ⚠️

Files with missing lines	Coverage Δ
src/MPSKit.jl	100.00% <ø> (ø)
src/algorithms/algorithm.jl	0.00% <ø> (ø)
src/algorithms/groundstate/gradient_grassmann.jl	85.18% <100.00%> (+10.18%)	⬆️
src/algorithms/groundstate/idmrg.jl	99.35% <100.00%> (+0.11%)	⬆️
src/environments/infinite_envs.jl	89.24% <100.00%> (+0.49%)	⬆️
src/states/ortho.jl	86.61% <91.30%> (+2.33%)	⬆️
src/algorithms/grassmann.jl	80.50% <72.72%> (ø)
src/algorithms/groundstate/dmrg.jl	96.84% <94.00%> (-3.16%)	⬇️
src/algorithms/groundstate/vumps.jl	81.11% <68.57%> (-5.20%)	⬇️

... and 7 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lkdvos]

Note; will remove the AI clutter here tomorrow, didn't feel like writing the PR notes but this is kind of bad

[VictorVanthilt]

I would keep this controllable via the verbosity interface.
I'm not sure about adding the timing output as one of the return values of find_groundstate, do you see yourself using this?

[lkdvos]

Fair point, probably just showing is enough. Any comments on the multithreading? I am not sure if I can do a lot better without having to do a lot of engineering, I don't even know where I would start in order to get something that is consistent.

[VictorVanthilt]

Maybe we can just update some of the names of the steps to indicate they are multithreaded. Getting some sort of average runtime per thread looks to be rather difficult. I didn't find an easy way in the TimerOutputs.jl readme.

[lkdvos]

No, TimerOutputs doesn't actually provide that much multithreading functionality. I think the claim is that the top sections are accurate, and the multithreaded parts below aren't. Any suggestions on names?

[VictorVanthilt]

Maybe just localupdate (threaded), envs (threaded), ...

[lkdvos]

For now I will just merge this as is, since this shouldn't be breaking I can always alter it later if people are unhappy, and I have limited time and want to keep things moving forwards a bit.