Activity

1. NicholasMartens

   added

   bugSomething isn't workingSomething isn't working

   on May 11, 2026
2. github-actions commented on May 11, 2026

   

   github-actionsBot

   on May 11, 2026 – with GitHub Actions

   Contributor

   More actions

   Triage note from automated investigation.

   I dug into the desktop app to see what could be keeping things busy when workspaces are idle. I couldn't write a bun:test reproduction — this is a runtime resource-consumption issue in Electron (RAM/CPU under load with many workspaces), which unit tests don't measure — but I did find several concrete contributors worth sharing:

   1. Main window background throttling is disabled unconditionally on macOS.
   apps/desktop/src/main/windows/main.ts:135 calls window.webContents.setBackgroundThrottling(false) whenever the app is on macOS. The comment above it explains why (macOS Sequoia+: background throttling can corrupt GPU compositor layers), but the effect is that the entire renderer — and every embedded workspace webview hosted in it — keeps running at full speed even when Superset is not the focused application. There is no blur/hide handler that re-enables throttling when the user switches to Chrome/Cursor.

   2. All 12 workspaces share a single renderer process.
   Workspaces are not separate BrowserWindows; they are panes/webviews inside the one main window. Per-pane webviews do call wc.setBackgroundThrottling(true) (apps/desktop/src/main/lib/browser/browser-manager.ts:49), but the host renderer's throttling overrides that on macOS while the app is unfocused.

   3. No workspace visibility tracking in the renderer.
   There is no code that pauses timers, animations, or React work for non-active workspace tabs — every mounted workspace continues to render/animate even when only one is visible.

   4. Several always-on intervals in the main process (smaller contributors):

   • apps/desktop/src/main/index.ts:288 — parent-process liveness check every 1s
   • apps/desktop/src/main/lib/host-service-coordinator.ts:487 — adopted-process liveness check every 5s per workspace
   • apps/desktop/src/main/lib/notifications/notification-manager.ts:54 — notification sweep every 5min
   • apps/desktop/src/main/lib/auto-updater.ts:322 — update check every 4h

   The biggest lever is almost certainly #1 + #3: re-enable background throttling on the main window when the app loses focus (using the existing invalidate() workaround on regain to avoid the GPU-layer corruption the team originally hit), and add visibility-based suspension for non-active workspace tabs.

   I'm not opening a PR because (a) the fix touches sensitive GPU-throttling code with a documented prior regression, and (b) there's no good way to land it behind a unit test — it needs manual validation on macOS Sequoia+ with multiple workspaces. Flagging for a maintainer to take from here.

   Refs #4412
3. saddlepaddle

   changed the title [-][bug] the title of bug report[/-] [+]CPU Performance issues in V2[/+] on May 11, 2026
4. NicholasMartens commented on May 14, 2026

   

   NicholasMartens

   on May 14, 2026

   Author

   More actions

   I noticed the power usage kept going up and up, so I decided to remove some work spaces and to restart my computer, and now it seems to be better:

   

   So maybe this was a memory leak or something, I don't know.
   I also noticed that it updated to a later version, I'm currently on: v1.9.1
5. Kitenite commented on Jul 11, 2026

   

   Kitenite

   on Jul 11, 2026

   Member

   More actions

   Closing as a duplicate of #5602, the consolidated tracker for stale performance issues from the July 2026 stale-issue sweep (no activity since 2026-06-01). If this still applies on a current build, comment on #5602 and we'll reopen.
6. Kitenite

   closed this as a duplicateof [Tracker] Performance & resource usage (stale-issue sweep, July 2026) #5602 on Jul 11, 2026