Native views, half the memory: what moving SolKube to NSH changed

SolKube has been rebuilt twice in its short life. It started as a React app on GPUIX, moved to Rust on GPUI, and this week moved again to NSH, which draws with AppKit on macOS and GTK 4 on Linux. Every feature carried over: the hot bar, the live dashboard, the tables, YAML with dry runs, the pod shell, Helm and port forwards.

We measure every build with the same script before we decide anything, so we can say exactly what the last move bought.

The numbers

These are medians from bun run bench on a MacBook Air (Apple M3, 16 GB, macOS 27), with both builds measured on the same day.

	GPUI build	SolKube on NSH	Change
Memory at rest	50.5 MB	24.8 MB	2.0× less
Memory after a minute of use	113.9 MB	29.9 MB	3.8× less
CPU while idle	0.78%	0.13%	6× less
CPU during light use	6.07%	3.42%	1.8× less
Launch to first window	270 ms	271 ms	level

Memory here is the physical footprint, the figure in Activity Monitor's Memory column. CPU is a share of one core over 60 seconds.

Why memory dropped

A GPU-drawn UI owns its pixels. GPUI keeps glyph atlases, image textures and frame buffers on the GPU, and on Apple silicon that memory is charged to the app's footprint. The more of the window you touch, the more textures it keeps, which is why the GPUI build grew from 50 MB to 114 MB after a minute of scrolling and opening panels.

With native views, AppKit and the window server draw text and controls. The app describes what to show; the system keeps the backing stores. SolKube's own footprint is mostly its data: the cluster model, the tables and the YAML you have open. After the same minute of use it grows by about 5 MB.

Resident memory (RSS) tells a different story, and it's worth knowing why. Both builds sit at about 104 MB of RSS at rest, because RSS counts every resident page the process maps, including shared system frameworks that every Mac app maps anyway. The footprint counts what the app itself owns, so it's the number that tracks what SolKube costs your Mac.

Why idle CPU dropped

A GPU renderer redraws frames: on a cursor move, an animation tick or a timer. Even with damage tracking, a window with live data wakes the render loop often. Native views redraw only the views whose content changed, and the system coalesces those updates with everything else on screen.

SolKube's dashboard still refreshes every few seconds and its numbers still roll to new values. Those animations run on the platform's animator as transforms and opacity, so between updates nothing in the app runs at all. Idle CPU fell from 0.78% to 0.13% of one core.

What didn't change

Launch time stayed at about 270 ms on both builds. Both are Rust binaries that open a single window, so there was little to win. The difference between 270 and 271 ms is well inside the run-to-run spread, so we call it level.

Light-use CPU also moves more between sessions than the other numbers: the same build has measured 5.7% and 9.3% an hour apart on the same Mac. We only compare light use between runs made back to back on one machine, which is what the table above does.

Where we started

For scale, the first SolKube prototype was React components on GPUIX. On an M3 Max it took 678 ms to open its window and rested at 159 MB. The GPUI build cut that to 277 ms and 68 MB on the same Mac, and NSH has now halved the memory again. Every run is on our benchmarks page, with the method and the raw numbers.

What's next

The numbers that matter most to someone choosing a Kubernetes client are the ones against the tools they use today. We'll measure Lens, Freelens and Headlamp on the same Macs with the same script, and publish the results whichever way they go.