Performance: lighter memory and smoother under heavy load
We spent the week on performance: reducing memory consumption, smoothing out git hitches, and cutting background CPU.
Every number below is a measured before/after, not an estimate.
TL;DR
- Less memory, fewer crashes. Sessions with lots of terminals stay responsive and are far less likely to white-screen, even on 8 or 16 GB machines.
- Renderer memory 1,127 → 838 MB (−26%)
- JS heap 581 → 286 MB (−51%)
- 4× fewer GPU contexts
- No more hitching from git. Switching branches or changing lots of files at once no longer stutters the app.
- Worst-case stall on the UI thread 82.3 → 28.0 ms (3× smaller)
- Typical stall 24.5 → 9.5 ms
- Quieter in the background. Port detection uses far less CPU, so quieter fans and better battery, even with many terminals open.
- Background scans 15 → 1 per cycle (15× fewer)
- Idle terminals scan every 30s instead of every 2.5s (12× less)
Lower Memory When You Keep Many Terminals Open #5751 #5754
Every hidden terminal used to keep its full scrollback and a live GPU context, forever. Open a lot of them in one session and memory could climb past a gigabyte.
Now Superset keeps only your most-recent terminals in memory. The rest are saved to disk and rebuilt when you switch back. The process behind each one keeps running the whole time, so nothing is lost.
The test: 16 background terminals, each filled with about 5,000 lines.
| Metric | Before | After |
|---|---|---|
| Terminals held in memory (GPU contexts) | 16 | 4 |
| Scrollback lines retained | 80,016 | 20,004 |
| Renderer JS heap | 581 MB | 286 MB (−51%) |
| Renderer process memory (RSS) | 1,127 MB | 838 MB (−26%) |
Renderer memory with 16 terminals open drops from 1,127 MB to 838 MB, a 26% reduction
Live GPU contexts held in memory drop from 16 to 4 with 16 terminals open, 4 times fewer
You set the limit in Settings → Terminal → Background terminal memory (default 12).
Active terminals are never touched, and neither are running TUIs like vim or a coding agent. Hidden in-app browser tabs are offloaded the same way, and rebuilt when you switch back.
Smoother While Git Churns in Big Repos #5750 #5746
In big repos, git status used to run on the same thread that streams your terminal output. So a branch switch, or a burst of file changes across several workspaces, could make the whole app hitch.
That work now runs on a background pool of workers. Large batches of file-change events are capped instead of piling up.
The test: 8 workspaces churning a 20,000-file repo, with 600 files dirty.
| Metric | Before | After |
|---|---|---|
| File-watch stall, p99 | 31.7 ms | 10.7 ms |
| File-watch stall, worst case | 82.3 ms | 28.0 ms |
| Full status refresh, p99 | 24.5 ms | 9.5 ms |
| Full status refresh, worst case | 49.0 ms | 17.6 ms |
Worst-case main-thread stall under heavy git load drops from 82.3 ms to 28.0 ms
Typical main-thread stall (p99) under heavy git load drops from 24.5 ms to 9.5 ms
Lower is better here. It means the thread that keeps your terminals and UI responsive spends far less time blocked.
There's no setting to flip. It's on for everyone.
Lighter Background CPU From Port Detection #5723
Port detection spots a dev server and offers to open it. It used to scan the whole process table once per terminal, on every tick. The more terminals you had open, the more background ps processes it spawned.
Now it runs one shared scan per cycle, no matter how many terminals are open. Idle terminals scan even less often.
The test: the real scanner with 15 terminals registered, counting every ps spawn over 6 cycles.
| Metric | Before | After |
|---|---|---|
ps spawns per cycle | 15 | 1 |
Total ps spawns over 6 cycles | 90 | 6 |
Port detection with 15 terminals open drops from 15 background process scans per cycle to 1
Idle terminals scan every 30 seconds instead of every 2.5 seconds, 12 times less often
Idle terminals also slow down, from a scan every 2.5 seconds to every 30. They speed back up the moment they print output. So a machine full of quiet terminals nearly stops scanning.
More to come
This is just the start. We want Superset to be the one workspace you need to build software, and being fast is a big part of that. We'll keep pushing on performance every release.