There’s a comic version of this failure: you notice the fans spinning, open your system monitor to find the culprit, and the culprit is the system monitor. A monitoring app that costs real CPU isn’t a tool anymore. It’s a parasite with a dashboard.
So Readout carries budgets, in writing: at most 2% CPU with the popover closed, at most 5% with it open, and exactly zero helper processes when fan control is off. The current measurements on my M1 Max are 1.3%, 2.6%, and confirmed-absent, plus roughly nothing at all while the display sleeps, because it stops sampling entirely. Memory takes two numbers rather than one: 18 MB until you open the dashboard, 50–70 MB after. But the budgets are the boring part. The interesting part is what it took to hold them, and how I make sure I’d find out if they broke.
Measure the way the machine counts
First, an embarrassing measurement lesson. The obvious way to check an app’s CPU use, glancing at the %CPU column, is a decaying average that flatters and slanders by turns. The number that can’t argue is CPU time: read the total seconds consumed, wait exactly a minute, read again, divide. Every figure Readout publishes comes from that kind of soak, because the first version of my own self-measurement was off by thirty times, in my favor, and I’d rather not learn that lesson twice.
The expensive thing, skipped
The costliest work Readout does is answering “which app is using the network.” It means spawning a system tool and sweeping every process, several times a minute. The trick isn’t doing that efficiently. It’s noticing when it needn’t be done at all:
| Condition | Behavior |
|---|---|
| Under 500 KB moved lately | Skip the sweep entirely; nothing worth attributing happened |
| Serious thermal pressure | Stand down; never add load to a struggling machine |
| Popover just opened | Sample immediately; the data is fresh exactly when eyes arrive |
A monitor spends most of its life unwatched next to an idle machine. Designing for that case, not the demo case, is where the whole budget lives.
The part I’m proudest of
Budgets decay silently, one feature at a time. So Readout watches itself in production, with the same skepticism it points at everything else: if it exceeds about 3% CPU averaged over a minute while idle, it writes the overrun to its own failure journal, the one it keeps for bug reports, and backs its tick rate off. The journal entry is the point. A regression I don’t hear about is a regression that gets to stay.
None of this is glamorous engineering, and that’s the argument. An instrument’s first duty is to not disturb the thing it measures. The needle should never move because of the gauge.