Tags: gridex/gridex
Tags
perf(query-result): unfreeze 3k-row Run path + loading overlay Three issues compounded into a 4-5 second UI freeze on big queries: 1. BuildResultHeaders deep-copied the entire QueryResult ONCE PER COLUMN into PointerReleased lambdas. For a 1817 row x 25 col result that's 25 copies of a million-wstring table — 4027ms measured (down to 81ms after switching to a single shared_ptr). 2. ResultsContainer.Children().Clear() destroyed ~47k XAML elements synchronously between runs. Capped rendered rows at 500 (with a 'showing first 500' status note) until ItemsRepeater virtualization lands — keeps worst-case clear under ~12k elements. 3. adapter->execute ran on the UI thread, so a 'Running...' overlay never had a chance to paint. ExecuteCurrentQuery is now a fire_and_forget coroutine that resume_background's the query call and ResumeOnDispatcher's back to render. WorkspacePage's OnExecuteQuery lambda now defers LogQuery to the page dispatcher so it doesn't touch XAML from the bg thread. Added a QueryLoadingOverlay (ProgressRing + 'Running query...' text) that shows immediately on Run and hides after first paint. Kept gridex-perf.log instrumentation in place — diagnostic value worth more than the trivial file-write cost; can strip later.
PreviousNext