A 9 MB menu-bar app and a 40 MB one feel identical from the menu bar. What separates them is not installed size. It is how many times per second each one wakes the CPU, and what it does on each wake.
It is a fair question to ask of any monitor, and it is asked of them regularly — in public threads about menu-bar monitors among other places — usually without a number coming back. The axis is the right one: a polling monitor's cost is its wake rate, not its download size. This post is Searoom's answer for itself, measured with the tool macOS already ships for exactly this question.
The headline numbers first. At its default two-second sample interval, Searoom 0.7.0 on an otherwise idle M5 Pro adds about 4.2 wake-ups per second and uses about 0.36 percent of one core, with roughly 110 MB resident. At its most expensive setting, one sample per second, it adds about 9.5 wake-ups per second and 0.84 percent of one core. At its cheapest, one sample every ten seconds, it adds 0.8 wake-ups per second and 0.07 percent of one core.
What an idle wake-up is
When a Mac has nothing to do, the CPU drops into a low-power idle state. Waking it costs energy: Apple's energy guide states the cost directly — waking the system from an idle state incurs an energy cost when the CPU and other systems are awakened from their low-power, idle states.
Two counters matter. An idle wake-up is a timer firing while the CPU is in that idle state, forcing it out. Apple's own definition, from the same guide: Activity Monitor's Idle Wake Ups column reports how many times per second a timer fired, averaged over the sample interval. An interrupt wake-up is broader: interrupts that arrive and dispatch work, including inter-processor interrupts. A process can show interrupt wake-ups above its timer rate, because one timer fire triggers follow-on work — device reads, Mach messages — that arrives as more interrupts.
Why the count matters at all: each wake burns energy even when the work is trivial, and Apple's guide is explicit that if there are many timer-invoked wakeups, the energy impact is high. A monitor is a permanent resident. Its wake-ups run for as long as the Mac is on.
How Searoom is built for this
Searoom collects every metric from one serial DispatchSourceTimer on a utility-quality-of-service queue. There is no timer per metric and no second polling loop.
The timer carries leeway, the parameter that tells the system a fire time is approximate. This is the documented mechanism for batching timers systemwide: within the tolerance, the system shifts timer fires so that multiple apps' timers execute together, one wake serving all of them. Apple's guideline is to set the tolerance to at least 10 percent of the interval. Searoom sets leeway to 15 percent of the interval, capped at one second: 150 ms at the one-second cadence, 750 ms at five seconds, and the cap binding only from about six and a half seconds upward.
One documented detail matters for reading the results. dispatch_source_set_timer(3), the manual page behind schedule(deadline:repeating:leeway:), states it exactly: for the subsequent timer fires at start + N * interval, the upper limit is MIN( leeway, interval / 2 ). So Searoom's effective coalescing window is 150 ms at a one-second cadence, 300 ms at two seconds, 750 ms at five, and one second at ten. The same page notes that the lower limit on delay is the system's to choose and varies with process state, including whether an app's interface is visible — one reason these numbers are reported with the popover closed.
The measurement
The instrument is powermetrics, which ships with macOS and reads the hardware's energy counters. It requires an administrator password. The --show-process-energy sampler reports, for every process, per-second idle wake-ups, interrupt wake-ups, CPU time, and energy impact.
sudo powermetrics -i 5000 -n 48 --show-process-energy -f plist > out.plistThat command takes 48 samples of five seconds each — one four-minute window. The measurement ran five such windows, back to back, in ascending interval order:
| Condition | Sample interval | Popover |
|---|---|---|
| Baseline | Searoom not running | — |
| Fastest | 1 s | closed |
| Default | 2 s | closed |
| Slow | 5 s | closed |
| Slowest | 10 s | closed |
Each window got 60 seconds to settle after launch or cadence change. The interval was set by writing the app's own settings store, so the binary under test was the unmodified packaged 0.7.0. A separate, unprivileged ps sampler recorded Searoom's CPU percentage and resident size every 30 seconds as a cross-check.
The numbers
Every value below is the median across 48 five-second samples, with the mean alongside where the two differ. The medians describe steady state; the means run higher because of one regular event explained after the table.
| Metric | 1 s | 2 s | 5 s | 10 s |
|---|---|---|---|---|
| Idle wake-ups/s | 3.9 (3.7) | 1.4 (1.4) | 0.8 (0.9) | 0.2 (0.4) |
| Interrupt wake-ups/s | 5.6 (5.6) | 2.8 (2.8) | 1.4 (1.5) | 0.6 (0.7) |
| Total wake-ups/s | 9.5 | 4.2 | 2.2 | 0.8 |
| CPU (ms/s of one core) | 8.4 (10.4) | 3.6 (5.8) | 1.9 (4.4) | 0.8 (3.2) |
| CPU, share of one core | 0.84% | 0.36% | 0.19% | 0.08% |
| Energy impact/s | 1.5 (9.2) | 1.4 (8.9) | 0.4 (8.4) | 0.2 (8.8) |
| Resident memory | about 96 MB at launch, 110–123 MB across the run | |||
Three findings sit inside this table.
The cost tracks the cadence. Total wake-ups per second run at roughly 9.5 divided by the interval, and steady-state CPU at roughly 8.5 milliseconds per second divided by the interval. Halve the cadence and the cost roughly halves. The fit is close rather than exact: dividing the one-second figures predicts 4.75, 1.90 and 0.95 wake-ups per second at two, five and ten seconds, against 4.2, 2.2 and 0.8 measured, so the scatter is about 15 percent and the five-second point sits above the line while the others sit below. That is what one serial timer predicts, at the precision this many samples can support. The inference is ours; the numbers are the machine's.
No wake-up lands in the tight deadline buckets. powermetrics classifies timer wake-ups by how far ahead of their deadline they were allowed to drift. Across all 192 measured samples at every cadence, Searoom recorded zero wake-ups in the sub-2 ms and sub-5 ms buckets. Every wake it causes is a coalescible one, which is the leeway mechanism doing what Apple's documentation says it does. There is nothing here for timer coalescing to leave on the table.
The mean is higher than the median because of the history write. Once per minute, the app persists its trend history: one atomic write on a utility queue. In the samples containing that write, Searoom's CPU ran about 30 ms/s above steady state — roughly 150 ms of work per write, or about 0.25 percent of one core amortized over a minute. It is visible in the data as a spike every twelve five-second samples.
The energy-impact column is the clearest evidence for that reading, because its mean sits between 8.4 and 9.2 at every cadence while its median moves with the interval. A cost that does not change when the sampling rate changes is not the sampler; the history write is the one event in the app that happens on its own once-a-minute schedule regardless of cadence. The magnitude is larger than the CPU spike alone would suggest — energy impact is a weighted score that counts disk I/O far more heavily than processor time, and this event is a file write. A monitor that keeps history is not free; this is what the history costs.
What it means against the machine
Context makes the absolute numbers readable. The idle machine recorded about 2,066 timer interrupts per second across all CPUs before Searoom ran at all. At the default cadence, Searoom's 4.2 wake-ups per second are about 0.2 percent of that background. Even at the one-second cadence, its 9.5 are about 0.45 percent. The monitor does not register as a change in the machine's wake-up behaviour; that is the finding.
Package CPU power is the honest limit of this run. Baseline power averaged 483 mW with a standard deviation of 592 mW, and the per-condition means sat between 466 and 680 mW. Those deltas are inside the noise, so this measurement cannot resolve Searoom's contribution in watts — a quieter background, or a longer run, would have to make that case. What can be said is what the process attribution already shows: hundredths of a percent of one core at the default cadence.
The ps cross-check agreed in kind: at two seconds and slower, Searoom's lifetime CPU percentage read 0.0 to 0.1 percent throughout, and resident memory stayed in the 96 to 123 MB band. At the one-second cadence it read up to about 1 percent during the same windows in which powermetrics attributed 8 to 10 ms/s.
Measuring a monitor yourself
Nothing above requires trusting the author. Activity Monitor has a no-password path: View > Column shows an Idle Wake Ups column, which Apple documents as timer fires per second averaged over the sample interval. Open it, watch any menu-bar app sit idle, and read the number.
The finer instrument is the one used here:
# one four-minute window of per-process energy data
sudo powermetrics -i 5000 -n 48 --show-process-energy -f plist > window.plistRun it once without the app, once with, and compare the process rows. The -f plist output is NUL-separated binary property lists, one per sample; each contains a tasks array with idle_wakeups_per_s, intr_wakeups_per_s, cputime_ms_per_s, and energy_impact_per_s per process. On battery power, watch a full charge cycle's worth of these numbers against the battery menu's own energy estimate if you want the watts answer this run could not resolve.
Limits
These numbers belong to one machine, one evening, one macOS build, and one app version. They were taken on battery power with the popover closed, in fixed ascending order rather than randomized. The desktop session was not empty: an active development session ran in the background throughout, identical across conditions, which is why the system-wide comparisons are reported as shares rather than absolute savings. Opening the dashboard costs more than idling in the menu bar, and that cost is deliberately not measured here — this post answers the idle question only. The raw captures and the harness that produced them are not part of the site repository.
What the measurement does establish: a polling monitor can be cheap enough that the machine's own wake-up counters barely move, the variable that controls its cost is the interval the user picks, and the leeway mechanism that makes the remaining wakes batchable shows up measurably in the deadline buckets. Those are checks a reader can run on any menu-bar app, including this one.
The monitors themselves get the same audit: five free Mac system monitors compared on licence, coverage, and what each costs while it runs — the wake-up cost among the measured rows.