This weekend, developer Loren Brichter released a website claiming that Google Chrome for Mac — or more specifically its auto-update mechanism — was causing the WindowServer process on macOS to constantly have high CPU usage, damaging the performance of macOS, even on high-end machines.
The website includes information on how to completely get rid of Chrome and its updater from your Mac to get your performance back, and went as far as calling it “malware” (that word has since been removed). Many users have reported that this does work and that after removing Google Chrome from their machines, everything got a lot faster.
Let me preface this by making it very clear that I’m not a fan of Google Chrome. I do have it installed because some things that I do online require it, but my browser of choice has always been Safari. What piqued my interest was the technical side of this story, and some questions that I thought of while I was reading Loren’s report. Those questions were: Is it possible for a process to hide itself from Activity Monitor while it is running? When does the updater process run and what does it do? Is the Google Chrome updater actually the cause of this WindowServer CPU usage that people are seeing?
Is it possible for a process to hide itself from Activity Monitor while it is running?
I do not have a definite answer for this question. The only practical way I found to do this was to monitor the system for running processes and if Activity Monitor is found, terminate my process so that the user won’t see it in Activity Monitor. I don’t see why Google’s Keystone updater would have to do this, and some quick static analysis of its binaries hasn’t revealed any such tactic.
When does the updater process run and what does it do?
Google’s Keystone service, just like any other service-type apps and processes that run on a Mac, registers itself with the system by employing a launchd property list. Launchd is the daemon responsible for spawning processes on macOS, and a launchd property list is basically a configuration file that tells launchd how it is supposed to treat a given service.
In the case of the Google Chrome updater, it registers two services, which are backed by the same binary, located at ~/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/MacOS/GoogleSoftwareUpdateAgent.
The “Keystone User Agent” service has a StartInterval set to a value of 3623 seconds, so it will run roughly once per hour to check for updates. The other one, “Keystone XPC Service” is started only when a Google app wants to check for updates itself, on demand. These are not services that will keep running indefinitely, they are only started periodically to check for updates or when a Google app wants to talk to them, which makes the claim that they slow down WindowServer even more interesting.
As to what this updater agent does, I’ve done some basic reverse engineering by statically analyzing the binaries involved using Hopper. It seems to handle things such as uploading crash reports if any are available, as well as checking for updates of Google’s apps, such as Chrome. I have been able to see it in Activity Monitor while it is actually running, in which case it will appear as “Google Software Update.”
Note that this basic research is by no means confirmation that this piece of software doesn’t do anything potentially nefarious, it just means that in the limited time that I had to look into it, I didn’t find anything alarming.
Is the Google Chrome updater actually the cause of this WindowServer high CPU usage that people are seeing?
This was the main question I set out to answer during my tests. The tests were performed on a 2019 16” MacBook Pro with a Core i9 processor and 16GB of RAM. The machine was plugged into an external display, no other apps were actively doing anything other than basic background tasks during the tests and I also left caffeinate running to prevent the machine from sleeping.
Using Instruments, which lets you observe software metrics such as CPU usage over time, I recorded two sessions: One with Google Chrome installed and another one with Google Chrome and the updater services uninstalled. I’ve used the first 30-minute window of the Instruments session to measure the CPU usage of WindowServer in each scenario.
As you can see from the comparison above, with Chrome installed, the WindowServer process used about 50s of CPU during the test window. Without Chrome and its updater installed, it used about 49s. I don’t see this as a confirmation of the problem, given that the difference is negligible (way below what would cause visible performance issues).
Apart from that, the entire claim that a process which runs once per hour would cause a completely unrelated system service to have high CPU usage is wild. WindowServer is responsible for rendering the macOS UI to the screen, it spends its time in the CGXUpdateDisplay method, rendering CALayers, a task that has absolutely nothing to do with anything a software update checker (with no UI) would be doing.
Why are people assuming it’s Chrome slowing down their Mac performance?
As to why people are perceiving this problem and its solution, I can think of a few possibilities. One of them is the Placebo Effect: You have a problem, you do something that someone told you should fix the problem, and then you feel like the problem was fixed. This is more common in computers than you’d think. Another one is Confirmation Bias: You hate Google and Google Chrome (hey, not a fan either, we can be friends), and you see a story that matches your perception of the software, so you instinctively believe it.
Another thing that could be at play here is that the instructions on Loren’s website tell you to reboot the machine after performing the steps described, but that is not necessary in order to uninstall Google’s software updater. In fact, on my tests, I uninstalled it by ensuring it wasn’t running, then running launchctl unload, then removing the launchd property lists and binaries from the system. I did that because a computer that’s just been rebooted will always feel faster than one that’s been running for weeks, and I needed to eliminate that variable from my tests.
If you still feel like Google Chrome is slowing down your Mac performance, by all means, go ahead and remove it, I recommend Safari instead.
FTC: We use income earning auto affiliate links. More.
Comments