mix/gosentry
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

P6.3: correct startup measurement — ~400 ms on Fyne 2.7.4

Browse Source 
Previous commit used PowerShell process-launch timing instead of the
History tab metric. Actual warm-run figure from the in-app "Window shown
in …" event is ~400 ms, down from ~644 ms on Fyne 2.6.3 (~37% recovery).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
mixeme
2026-06-23 22:36:04 +03:00
parent f03f012c1b
commit c57d5b102f
1 changed files with 10 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/PERFORMANCE.md
+10 -28
View File
@@ -50,35 +50,17 @@ builds, so the comparison is fair.
### Finding (2026-06-23, Fyne 2.7.4)
**Fyne upgraded from v2.6.3 → v2.7.4** as part of Phase 6 (P6.1). Cold-start
measurement via PowerShell `Stopwatch` (launch to window creation):
**Fyne upgraded from v2.6.3 → v2.7.4** as part of Phase 6 (P6.1). Measured
using the same method as the 2026-06-22 baseline: the History tab "Window shown
in …" event, which records the span from application entry to `w.Show()`
completion.
| Run | Time (ms) |
|-----|-----------|
| Cold | 1286 |
| Warm 2 | 1213 |
| Warm 3 | 1217 |
| **Warm avg** | **~1215** |
**Warm-run average: ~400 ms** (down from ~644 ms on Fyne 2.6.3).
### Interpretation
The warm-run startup on Fyne 2.7.4 is approximately **~1215 ms** (launch to
window creation). This measurement includes GLFW window setup, driver
initialization, and w.Show() completion. The previous measurement on Fyne 2.6.3
was ~644 ms (via instrumentation); the difference reflects both:
- System load and timing-method variation between measurements (MSYS2 Bash
clock vs PowerShell Stopwatch; w.Show() completion vs window creation event)
- Possible additional overhead in this environment
The build compiles clean, all tests pass (go test -race), and Fyne 2.7
changelog reports "Massive performance increases on rendering" with no
breaking API changes. The tray and window interaction features (P6.2) depend
on 2.7's `SetSystemTrayWindow` API, which landed in v2.7.0 and is confirmed
working.
### Next check
If measurement precision becomes critical, reimplements the **`GOSENTRY_TIMING`
instrumentation pattern** from the previous finding (environment-gated phase
timers across `src/ui/run.go` and `src/ui/mainwindow.go`), which gives
microsecond-level breakdowns rather than coarse system-timer buckets.
Fyne 2.7 recovered roughly **~240 ms** (~37%) of the `w.Show()` regression that
arrived with the 2.6 threading model change. Fyne 2.7.0's "Massive performance
increases on rendering" and driver/threading optimisations are the likely cause.
The upgrade is a net win: the `fyne.Do` threading API (required since 2.6) is
retained, and the primary startup cost is substantially reduced.