n0shake
[BUG] CPU usage randomly hight in MacOS 26.x Tahoe
Have reported this via email too, but randomly the CPU used of Clocker in Tahoe will jump to about 50% and stay stuck there on MacOS 26 (betas, 26.0 Release, and 26.1 release.
Would love to see this fixed.
@n0shake sorry to ping you directly. Do you have a clue what could be causing this?
Is this code up to date with the version from the App Store? I'm asking that because I tried to run it locally to see what is going on, and the version in the pbxproj is 22.03 and the minimum deployment target is 10.13.
https://github.com/n0shake/clocker/blob/fb0e54c9e85d388f5c9bcb890a0771e74e338853/Clocker/Clocker.xcodeproj/project.pbxproj#L1614-L1615
I had to bump to 10.14 there because there are some methods being used in the codebase that are only available on 10.14.
This does seem to be different to #126, disabling all calendar integration still sees 50%ish CPU usage on Tahoe.
I'm seeing the same issue. I have version 24.03 (113) installed from the App store, on Tahoe 26.1. The calendar integration disabling did not make a difference.
I tried bumping to 10.14 and building locally and I didn't run in to any CPU usage issues in 3 hours of testing.
Interesting, did you interact with the app? I've done the same, and I have high CPU usage.
One thing that I've noticed. When I start my OS, I don't see any CPU spike, and it only happens the moment I interact with the app (opening the menu, settings, etc).
Same. v24.03 (113) installed from App Store on MacOS 26.1 (Intel MacBook Pro). I've used Clocker for years without problems, but only just noticed my laptop is working hard because of it - only recently updated to MacOS 26.1, so presume it's related.
I've created a Spindump and AI has summarised the root cause and the fix to be:
Clocker recreates date/time formatters (NSDateFormatter objects) on every single frame when drawing the menu bar icon. Creating these formatters is extremely expensive because it has to load language/locale data from disk each time.
Cache the date formatters once at startup and reuse them, instead of creating new ones every frame. This is a common iOS/macOS programming mistake.
It turns out my initial assumption was wrong.
If running in the Applications folder the CPU usage is high, if it's running from e.g. the Xcode output folder it's very low. So it's something that depends on its running in that folder. Most of the work is being done updating the status item it appears, unclear why being in the Applications folder changes that.
A little out of context, I've been using this app as a temporary replacement while this is relevant, and it's fitting my needs:
https://apps.apple.com/us/app/zone-bar/id6755328989?mt=12
Edit: It's not free anymore.
I've been using this app form the same developer as the one @rubnogueira mentioned. It's included in the SetApp subscription too if you have that.
https://sindresorhus.com/dato
I prefer Clocker, so hopefully it gets upgraded, or the developer passes it along to a new maintainer.
I've created a Spindump and AI has summarised the root cause and the fix to be:
Clocker recreates date/time formatters (NSDateFormatter objects) on every single frame when drawing the menu bar icon. Creating these formatters is extremely expensive because it has to load language/locale data from disk each time. Cache the date formatters once at startup and reuse them, instead of creating new ones every frame. This is a common iOS/macOS programming mistake.
This lines up with the symptoms I observe on Tahoe.
When no timezone is displayed in the menu bar, Clocker uses very little CPU, and start to use ~60% when one or more timezone are displayed.
Same here. 50-60% CPU is being consumed on Tahoe 26.1 Switched to this so far: https://apps.apple.com/tr/app/menubarclock/id492167985?mt=12 // MenubarClock
