epic(perf): steady 120 Hz without drops (profile findings, Sep 2026) #987

Activity

1. ZhuchkaTriplesix

   added

   epicEpic / umbrella issueEpic / umbrella issue

   performanceTheme parser epic label: performanceTheme parser epic label: performance

   on Sep 25, 2026
2. ZhuchkaTriplesix

   added a commit that references this issue on Sep 25, 2026

   Merge pull request #988 from QueryaHub/perf/120hz-investigation

   ...

   7700a55
3. ZhuchkaTriplesix commented on Sep 27, 2026

   

   ZhuchkaTriplesix

   on Sep 27, 2026

   MemberAuthor

   More actions

   Status update — 2026-09-27

   Went through all six children this cycle. Summary of what shipped, with measured before/after where it exists, and honest notes on where a fix didn't move the needle or wasn't attempted at all.

   Closed

   • perf(grid): semantics tree is rebuilt for every visible cell (~17 ms per result set, hidden from FrameTiming) #981 grid semantics rebuilt per cell — fixed.
   • perf(grid): first frame of a new result set spends ~35 ms in layout #982 grid first-frame layout cost — partial: shipped column-width caching. Measurable but modest improvement; the deeper fix (custom RenderObject / row-batch renderer) was scoped out as higher-risk than warranted for the remaining gain.
   • perf(grid): column-window shift during horizontal scroll builds heavy cells (12-50 ms frames) #983 grid column-window shift builds heavy cells — partial: shipped grid-level tap/double-tap/cursor hit-testing (removes a GestureDetector+MouseRegion per visible cell). Benchmarked (grid_perf_bench.dart MODE=select, 5000×120): build p50 3.53→2.88ms, total p50 11.69→9.09ms, frames>8.33ms 312/372→264/371. Secondary-tap/context-menu/tooltip hoisting and a full custom-RenderObject rewrite remain out of scope.
   • perf(workspace): switching SQL tabs builds up to 8 ms in one frame #985 SQL tab switch build cost — fixed (VerticalSplitPane caching, from earlier in this cycle).

   Still open

   • perf(shell): sidebar toggle re-lays out offstage workspace layers and LayoutBuilders every frame #984 sidebar toggle — partial: shipped LazyOffstage, which skips re-laying-out hidden QueryaSwitchingBody layers every animation frame (verified correct with a dedicated test). Benchmarked honestly: no measurable difference in the bundled sidebar_toggle scenario (build p50 3.5ms before/after), because the dominant cost there is the visible tree's own LayoutBuilder rebuilds reacting to the changing width, not the hidden layer's layout. That remaining piece needs restructuring _MainContentSplitState so the workspace's laid-out width doesn't change during the toggle at all (reserve final width immediately, animate the reveal via clip/transform) — a bigger, riskier change to a central screen (main_screen.dart), not attempted yet.
   • perf(linux): app is capped at 60 fps because the GTK embedder has no vsync #980 Linux capped at 60fps — not attempted. Root cause is the GTK embedder having no vsync (upstream flutter/flutter#192342), which is likely an engine/embedder-level issue rather than something fixable from app code. Worth a scoped investigation before committing effort, but that investigation hasn't happened yet.
   • epic(perf): Connections sidebar FPS / frame budget @ 120 Hz #723, qa(motion): Fluid shell + connections tree DevTools sign-off @ 120 Hz #739 — tracking/QA sign-off issues, not independent code fixes; epic(perf): Connections sidebar FPS / frame budget @ 120 Hz #723 already notes the connections tree measured within budget at 1500 tables.

   Net effect

   Every scenario in the original profile table has a closed or measurably-improved issue against it except the sidebar toggle (partially improved, real bottleneck untouched) and the Linux vsync cap (untouched, may not be fixable here at all). Given the remaining work is either high-risk-for-uncertain-gain (#984's Row restructure) or possibly not our issue to fix (#980's embedder cap), pausing here rather than continuing to grind on partial increments — flagging both for a deliberate decision on whether/how to pursue them next.
4. ZhuchkaTriplesix commented on Oct 12, 2026

   

   ZhuchkaTriplesix

   on Oct 12, 2026

   MemberAuthor

   More actions

   Re-measurement on dev/main (2026-10-12)

   benchmark/app_perf_bench.dart, profile build, Linux, 120 Hz display, window 2056x2616, 5000 rows x 20 cols, tree of 1500 tables.

   Scenario	build p50 / max (ms)	raster p50 (ms)
   sidebar toggle	2.2 / 3.9	1.0
   run 5000-row query	10.9 / 50.5 (4 frames)	1.2
   grid scroll vertical	1.1 / 1.7	0.7
   grid scroll horizontal	0.1 / 7.8	0.7
   hover over grid	0.1 / 0.2	0.7
   typing in editor	2.5 / 3.2	0.8
   tree expand / scroll / collapse (1500)	0.5 / 0.8 / 0.6 (max 4.9 / 1.6 / 1.3)	0.8-0.9
   new tab and switch	1.1 / 3.6	0.8
   run in 1 of 5 tabs	0.2 / 6.7 (1 pane rebuilt)	0.9

   Reading:

   • Everything but the first frame(s) of a new result set is inside the 8.3 ms budget; raster is ~1 ms everywhere.
   • Running a 5000 x 20 query is the only visible hitch left: 50.5 ms max build (~6 frames at 120 Hz). Worth re-profiling with PROFILE=true to see what is left after perf(grid): semantics tree is rebuilt for every visible cell (~17 ms per result set, hidden from FrameTiming) #981/perf(grid): first frame of a new result set spends ~35 ms in layout #982.
   • Every scenario still presents at 60 fps (engine cap, perf(linux): app is capped at 60 fps because the GTK embedder has no vsync #980).
   • "typing: 29 fps" is the bench's typing cadence, not dropped frames (build 2.5 ms).
   • Note: the erd_open_200 scenario times out on current dev; tracked separately (see the new issue).
5. ZhuchkaTriplesix commented on Oct 12, 2026

   

   ZhuchkaTriplesix

   on Oct 12, 2026

   MemberAuthor

   More actions

   Follow-up: where the run_heavy_query hitch comes from (call-path analysis, same machine and build)

   What was measured, and what turned out to be noise:

   1. Phase split of the hitch frame. With debugProfileBuildsEnabled / LayoutsEnabled / PaintsEnabled the timeline for the 5000 x 20 run shows BUILD 9.0 ms total (30 builds) and LAYOUT 53.4 ms in 7 frames, i.e. the ~50 ms frame is layout, not build. (These flags add per-object timeline events, so leaf numbers such as RenderParagraph 43 ms for 242 paragraphs are inflated; a clean paragraph layout is 10-20 us, see below.)
   2. Text layout is not the cause for Latin data. TextPainter.layout is 10-20 us per paragraph for ASCII / Cyrillic / Latin-extended in every font-family variant (monospace, a concrete installed family, a missing family, the 10-family editor stack). Only CJK is slow (~400 us, 40x); filed separately.
   3. Native font lookup (FcPatternGetString, FcStrCmpIgnoreCase, FcPatternFilter) in the CPU profile comes from that fallback path; replacing 'monospace' by a concrete family in the grid changed the max build only from 47-52 ms to 38-45 ms (n = 2 each), so it is not the main cost.
   4. GC on the UI thread is large. Without the Dart timeline stream (which inflates GC), one run_heavy_query scenario shows ~35 young-generation collections on the UI thread totalling ~200 ms (~5.7 ms each, i.e. a frame each at 120 Hz) plus 30-60 ms of old-generation work. That points at the allocation volume of the result path (List<List<Object?>>, per-cell strings), not at layout; see perf(database): CompactResultDataset.fromRawRows formats every cell during type detection; split it and sample #1548, perf(results): carry the columnar dataset to sort / filter / export instead of List<List<String>> (memory 68 -> 17 MiB at 50k x 20) #1549, perf(results): build typed columns directly from the driver stream instead of collecting List<List<Object?>> first #1552.
   5. Noise to ignore: in the app benchmark's CPU profile the JSON parsing, _OneByteString.==/hashCode and LinkedHashMap lookups are caused by the VM-service client itself (the call chains end in VmService._processMessage / createServiceObject).
   6. Ruled out: the PostgreSQL / MySQL decoders do not block the UI isolate (event-loop stalls 0-2 ms at 50k rows for PostgreSQL, 4-15 ms for MySQL), so moving drivers into a worker isolate would not remove a hitch; SQLite row[col] lookups cost 1.8 ms for 5000 x 20 (row.values is not faster).

   Note on Linux fps: a profile build from flutter run uses the stock engine (60 fps). Release builds splice the vsync-patched engine (scripts/linux/apply_patched_engine.sh), verified on the installed package.
6. ZhuchkaTriplesix commented on Oct 12, 2026

   

   ZhuchkaTriplesix

   on Oct 12, 2026

   MemberAuthor

   More actions

   Memory finding from the same session as the CPU work: every result grid that is shown stays alive for the rest of the session (~5 MB per run at 5000 x 20; 6 re-runs -> 6 live grid states and datasets), and closed tabs retain their editor, results tab, grid and dataset. Root cause and the two-line fix are in #1555 (P1). Caches in lib/ were audited and are bounded (highlighter pair cache 12, intern pool 4096, connection pools LRU, Redis history 200); _gridSchemaCache is the only one without a cap but is cleared on writes and bounded by table count.