Last month I sorted Activity Monitor by CPU and found a menu bar app sitting at 1.9%, which it was spending to show me four numbers.
My first reaction was probably the same as yours: so what? Two percent of one machine. Nobody has ever noticed two percent.
Then I did the math on it.
The math nobody does
Menu bar apps are background software. They have no window, they do one small job, and they run for every minute your Mac is awake. That last part is what makes the cost worth checking.
A percent of CPU inside an app you open for ten minutes is free. Nobody will ever find it. The same percent inside something that never stops running is a tax you pay from the moment you log in until the moment you close the lid. It is on your battery, on your fans, and on whatever you were actually trying to do.
So here is the number I hold these things to: under a tenth of a percent of CPU, and under 50 MB of memory, for a utility that polls something once a second.
Plenty of apps clear that easily. Plenty do not, and the ones that do not are almost never doing more work. They are doing the same work less carefully.
Measure it in one command
You can check this yourself in about thirty seconds. Do not use Activity Monitor. It is fine for a glance, but you are reading a moving number off a window that is itself burning CPU to draw itself. Use top:
top -l 2 -s 1 -stats command,cpu,mem,th | grep -i YourAppThe -l 2 is the part almost everyone gets wrong, including me, for about a week.
The first sample of any top run does not report CPU over an interval. It reports CPU cumulative since the process launched. So if you read it, you are reading an average over the app's entire lifetime, which flatters whatever has been running longest and tells you nothing about right now. Take two samples and read the second.
Do it while you are not touching the app. The state that matters is the one these things spend almost all of their life in: sitting there, idle, nobody looking at them.
What the numbers actually mean
Once you have a reading, here is how to read it.
- CPU mean under 0.1%. Good. The app is sampling on a sensible cadence and not doing housekeeping on every tick. Leave it alone.
- CPU mean above 1%. Something is wrong. It is usually one of exactly two things, and I will get to those in a second.
- Memory above 100 MB. For an app with no documents, this is almost always a rendering pipeline that got brought up and never torn down.
- Thread count in the dozens. Not fatal on its own. But for an app polling a handful of counters, it suggests a thread per job instead of one timer doing all of them.
The two mistakes behind almost all of it
Shelling out to a command line tool on a timer. Spawning a process is enormously more expensive than reading the same information through a syscall. Do it once a second, forever, and you get exactly the kind of number I found in Activity Monitor.
Redrawing on a schedule instead of when the data changes. If nothing has changed, there is nothing to draw, and an app that redraws anyway is paying for a frame nobody can tell apart from the last one.
The memory case has a specific culprit on macOS. A chart drawn with SwiftUI's Canvas costs a fixed 93 MB the first time it renders, and never gives it back, which is a whole post by itself.
So do I uninstall everything?
No. Check what you are getting for the money first.
Some of these tools do a genuinely enormous amount. Weather, notification history, per sensor configuration, years of graph history: those are real features and they justify a real footprint. The ones worth replacing are the ones charging you a percent of CPU to put four numbers in your menu bar.
And if you do compare, compare properly. Sample every candidate in the same window, with the same command, on the same machine, in the same state. Numbers taken minutes apart on a machine whose load is drifting are not a comparison, they are two anecdotes.
That is the method behind our own benchmark, which puts AirStats at 0.046%, the iStat Menus suite at 0.116%, and Stats at 1.931%. Stats was the 1.9% I found in Activity Monitor, and it is where all of this started.