Electron vs Rust Desktop Memory: Measure Working Sets, Not 290MB Headlines
Discord's Rust desktop client is being quoted at roughly 290MB of RAM, and that figure is being used to settle the Electron argument. This video doesn't argue the number up or down — it shows what to measure instead. What the video covers: - Why a single idle-RAM figure from an unnamed build, at an unspecified uptime, under an unspecified workload tells you almost nothing about framework cost. - Why summing WorkingSet64 across a Chromium process tree counts shared pages (binary, ICU data, fonts, V8 snapshot) once per process, which is how most "Electron is using 2GB" screenshots happen. - The counter to use instead: summed private working set across the process tree, sampled over time, read with Get-Counter's Working Set - Private rather than Get-Process. - Why Task Manager, Activity Monitor and ps disagree on the same app, and why mixing tools means you measured the tools. The post also walks through the repeatable rig: a fixed workload script (launch, idle, open a channel with history, join voice, hands off), a thirty minute sampling loop, and the slope calculation that separates a large baseline from an actual leak. Sample output in the article is labelled illustrative — there is no measured Discord-versus-X benchmark there, and the numbers the outlets repeat are separated from what is confirmed reporting. Every command runs against your own app: performance counters on Windows, smaps_rollup on Linux, footprint on macOS. Full write-up: https://hackyjs.com/posts/electron-vs-rust-desktop-memory-measuring-working-sets-instead-of-trusting-290mb-headlines