So I was reading Howard Oakley’s Eclectic Light Company blog, as I often do (and you should too), and he mentioned the taskpolicy command line app, which I wasn’t aware of before. taskpolicy allows you to demote a process to “background priority,” making it run more slowly by giving it a lower priority for its disk and network access and – key point here – on M1-powered Macs, also runs the process on the M1’s efficiency cores instead of on the performance cores.
That got me thinking… if there’s a command line tool to do this, there must be a system API to make this happen, too. And lo and behold, the setpriority( ) system call will actually perform this neat trick, even though the man page lies and says it won’t.
I made some changes to App Tamer yesterday to add this, and App Tamer now has a new checkbox:
Turn the checkbox on, and whenever an app isn’t frontmost, App Tamer will give that app background priority, reducing its disk and network priority and switching it over to run on an M1 efficiency core. Running a few apps that consume quite a bit of CPU looks like this in Activity Monitor:
In my initial testing, the feature seems to work quite nicely. App Tamer automatically moves apps between the performance and efficiency cores as you switch between apps. So far, I haven’t found any downsides to this – but then again, I just added the feature yesterday and have only done limited testing. It’d be great to actually quantify whether this delivers additional battery life.
If you’d like to give it a try, you can download App Tamer 2.7d1 here. Just unzip it and run it, then click on a cpu-hungry app in App Tamer’s process list and turn on “Run this app on an M1 efficiency core” – that’s it. App Tamer will automatically lower the app’s priority when it isn’t frontmost.
Update: There’s now a beta version of App Tamer 2.7 that includes an almost-finished version of this feature.
Note for users of Intel-based Macs: On your machine, the checkbox is named “Run this app as a low-priority process” because your Mac doesn’t have separate efficiency and performance cores 😢. The app will be demoted to background priority so it uses fewer CPU and I/O resources, but I’m afraid there’s no fancy cpu-juggling involved.
For what I do, it would be nice to promote an app from the efficiency cores to the performance cores. The battery life hit would be minimal since my app doesn’t execute for long, but it would be nice to speed it up a bit.
I do read Howard’s blog every day and it is priceless!
That’s the one fly in the ointment. To reiterate what Howard found: If a developer explicitly sets a process’ priority to 9 (meaning that it’s expected to always be a background task), it can’t be elevated to run on the performance cores. Note that this _only_ applies to processes that are hard-coded to run as background tasks – such as backupd, the Time Machine backup daemon. Any process that doesn’t explicitly relegate itself to being a background task can be moved back and forth between the efficiency and performance cores.
What specific app are you wanting to move onto the performance cores?
The app is TeXshop a TeX and LaTeX typesetting app.
If I had read Howard’s site carefully, I would have seen that what I want is currently impossible in macOS. He confirmed this in an article posted on 1/24 (yesterday). Too bad.
Just to double-check, what _specific_ app or process is running on the efficiency cores that you want to promote to the performance cores? TeXshop itself seems to switch back and forth just fine when I use App Tamer to promote and demote it, and looking through the source code for the TeXshop app, I don’t see anywhere where it explicitly manages process priorities (which would be the only thing that would make it impossible to promote a background process).
The reason I’m belaboring the point is that I think Howard’s blog post is a bit misleading. Another person with whom I corresponded today misunderstood his post yesterday.
I did! And thanks for clearing that up. BTW, 2.7d1 is working perfectly for me.
When I look at the CPU History graphs and typeset my book (which takes about 1.5 seconds) I see a spike in both the E and P cores. The performance core spike is shorter than the one in the E cores. I am guessing that there is some process being relegated to the E cores. It might be ghostscript which I believe is used to create a pdf output file. The typesetting alone (to create a DVI file) couldn’t take much time for a 170 page book (well under a second). I might have some misconception about this whole process. Thanks for commenting.
Ghostscript would make sense – I could see that being wired to run on the E cores. But at 1.5 seconds of runtime, it’s not something that would even trigger App Tamer’s process management. That’d have to be changed in the actual Ghostscript code (which is doable, since it’s open source).
The only place in AppTamer where I can speed up an app is checking the box to speed up time machine backups. I checked the box and the behavior of TeXshop is the same – lots of tine spent in the E cores. Is there another way? Thanks!
To modify App Tamer’s handling of TeXshop, click on it in App Tamer’s process list while TeXshop is running. You’ll get a popover with options for throttling it and / or running it on the E cores when it’s in the background. If you leave all of the options unselected, App Tamer will let it run as fast as possible.
Thanks, it is difficult to click on the app in the process list since it runs so quickly (only lasts 1.5 seconds). Is there any way to modify its behavior before it runs?
For processes that run as subprocesses of another app (like Ghostscript, in the case of TeXshop), App Tamer applies the parent application’s settings to the subprocesses. So you can configure TeXshop and those settings will be applied to Ghostscript as well.
I’ll be adding “offline” settings in version 3 of App Tamer so the app doesn’t have to be running in order for you to see or change its settings.
Thanks, that sounds very useful. Is there a terminal command that can set the QoS without knowing the PID?
I’m afraid there’s not. The taskpolicy command is what you’d use from Terminal, and it requires the process ID.
[…] explained the basics of this feature in a previous post. It works like App Tamer’s other CPU-saving capabilities in that it’s applied to an app […]