Files
gosentry/docs/PERFORMANCE.md
T
mix 01fd572a89 Refactoring complete: v0.4.0 architectural milestone (#1)
## Summary

Completed Phase 5 refactoring and reached the target architecture.

**Architectural milestone achieved:**
- Service layer owns all state and is the sole writer
- UI is a thin Fyne view, all widget updates marshaled via `fyne.Do`
- Core engines are stateless and injectable
- Domain types are pure (no `yaml:"-"` fields)
- Full module builds and `go vet ./...` clean

## Changes

- Bump version: 0.3.6 → 0.4.0
- Update CHANGELOG with Phase 5 summary
- Add ROADMAP "Refactoring Follow-Ups" section

## Known follow-up work

1. **Linux test build broken** — `runner_test.go` needs `//go:build windows` tag
2. **File-size limits exceeded** — `operations.go` (486 lines), `jobs_view.go` (415 lines)

See ROADMAP.md for details.

---------

Co-authored-by: mixeme <mix.public@ya.ru>
Reviewed-on: #1
2026-06-22 08:05:10 +03:00

2.8 KiB
Raw Blame History

Performance Notes

Measured performance findings for GoSentry. Each entry records the method so the numbers can be reproduced and re-checked after relevant changes.

Startup Time

Finding (2026-06-22)

After the Phase 4 refactor, cold startup time (the History "Window shown in …" metric) increased by ~290 ms. The increase is caused entirely by the Fyne v2.5.3 → v2.6.3 upgrade (task T4.1), not by the Service / domain / UI restructuring.

Method

Env-gated phase timers (GOSENTRY_TIMING) were added across the startup path (Run in src/ui/run.go and newMainView in src/ui/mainwindow.go) and the equivalent points in the pre-refactor entry point (src/gui/app.go at commit c5e0ef9, the last commit before T4.1). Both were built with the CGO / MSYS2 UCRT64 toolchain and run 5× each; the first run of each is a cold-disk outlier and is excluded. The timed span (startedw.Show()) is identical in both builds, so the comparison is fair.

Results (warm-run averages)

Phase (cumulative from start) Old (Fyne 2.5.3) New (Fyne 2.6.3) Δ
after single-instance check ~0.5 ms ~0.6 ms
after Fyne app + window + tray ~277 ms ~285 ms +8 ms
app.Open() done +3 ms +3 ms 0
views built + svc.Start() +42 ms +43 ms ~0
after SetContent ~348 ms ~353 ms +5 ms
after w.Show() (TOTAL) ~348 ms ~644 ms +~290 ms

Interpretation

  • Everything up to and including SetContent costs the same in both versions (~350 ms). The refactor-specific code — app.Open() (~3 ms) and the new app.Service plus view construction (~42 ms) — is unchanged, so the restructuring added no measurable startup cost.
  • The entire regression lands in w.Show(): ~0 ms under Fyne 2.5.3, ~290 ms under 2.6.3. Fyne 2.6 reworked main-thread marshaling (the change that introduced fyne.Do) and front-loads first-window GL/driver realization into the Show() call.
  • The cost is a fixed, one-time Fyne expense, not a leak in GoSentry code, and the upgrade cannot be reverted because fyne.Do requires Fyne ≥ 2.6.
  • The tray / autostart path (--start-in-tray) skips w.Show() until the user opens the window, so it is unaffected.

Next check

Re-measure with the same method after the planned Fyne 2.6.3 → 2.7.x upgrade (see ROADMAP.md → Tray Interaction). The goal is to learn whether 2.7's driver/threading changes recover any of the ~290 ms w.Show() cost or hold it steady. Reuse the GOSENTRY_TIMING instrumentation pattern above; do not commit the temporary timers.