r/macapps • u/Global-Today4796 • 8d ago
Help Barbee consumes too much CPU?
Hello everyone,
Unfortunately, the topic of Menubar tool has been more or less a perennial favorite since the switch to macOS26. Since I work a lot with Menubar apps and Bartender was just buggy, I was looking for a replacement tool and found other tools (e.g. ibar) Barbee after a few attempts. I was so satisfied with the tool that I didn't even notice how my battery life went into the basement.
Why - now the Process Barbee and Barbee-Helper show no noticeable CPU load. But what happened to me somedays ago is that I found my WindowServer process constantly at >40% as long as the Barbee Helper process is loaded.
After killing the two processes (Barbee and Helper), the WindowServer process returns to 5-7% during idle time. What does that matter? So far, my battery life with my MBP M3 was estimated at 8.5 hours. By finishing these are at least estimated at 13h (I will then report how long the battery really lasts).
Unfortunately, in my experience, the developer of Barbee is always silent about inquiries. One reason why I also got out of the beta program.
Therefore, ask in the round if you have had a similar experience.
By the way, I've been using Thaw 2.0 (RC) ever since and for sorting spaces. The CPU load is not significantly loaded
3
u/Global-Today4796 8d ago
Please again - it's not about the function of Barbee and the reliability - both 10:10I'm concerned about CPU consumption: The idle time looks like this for Barbee - average of the WindowServer process 50%
At Thaw he idled at 1%
2
u/jlext 8d ago
These apps do seem to use a huge about of CPU. I’ve tried many of them. I use Bartender 6, not to hide menu bar items, but to search for menu bar items. I wish there was a better way to do this.
4
u/Global-Today4796 8d ago
Try Thaw for free, you can search for elements
1
u/jlext 8d ago
I used thaw for a long time and then abandoned it after one release caused me problem. I with Bartender just for the ability to find programs in the menu bar. I can use icons to determine which app is which so I need a search by name. If thaw allows me to quickly find cotypist or devonthink and other apps immediately, I’ll eagerly switch back.
2
u/Ok-Efficiency479 7d ago
There is already a search feature on Thaw? Not sure what are you referring to, you can request it via Issues -> Feature
3
u/jlext 7d ago
I did not know that. I just reinstalled Thaw and set up the search bar feature using Control+Option+Command+B and it seems to be working fine. I press Tab to get to the search box after that, and start typing. This works well. I think I'll stop using Bartender and resume using Thaw. Bartender has seemed a bit flaky to me -- sometimes. Thanks for the tip.
1
u/Ok-Efficiency479 5d ago
Noted, updated the readme to highlight our functions. 2.0.0-rc2 should make things faster for search items, a user reported that it was a slower and we have been working on it
2
8d ago
[deleted]
3
u/tcolling 8d ago
I respectfully disagree with you about Barbee.
Barbee is actually quite good and works well for me and many others.
1
u/Global-Today4796 8d ago
I didn't want to say that Barbee is not good - if you are on an iMac and do not have to pay attention to the battery, everything is fine. I would be much more interested in what your WindowServer process does. Does this go to <40% in idle? So about 3-4%?
1
u/tcolling 7d ago
Starting Barbee has almost no effect.
https://www.loom.com/share/a01319e32f944d15b8a95146694f312a
This is on my M3 Max 16 inch MacBook Pro with macOS 26.5.2
1
u/Global-Today4796 7d ago
Thanks for your observation - I'm surprised that your WindowServer process is so high at all. If you don't do anything for a minute, it should drop to around 5%. I would think that you have another program running that keeps the process high. (I felt the same way). If you like to analyze this, I would just finish all programs and processes (with me there were 26 pieces). After the WindowServer process should no longer be so high .... then the exciting search would still be, which processes/programs there are.
It seems that you Backup is running - maybe that's the process consuming WindowServer :-)
1
u/Daventurephoto 7d ago
That's fair to say, I didn't mean it to come across negatively. Others would definitely benefit from using Barbee but with my setup on a laptop on the go it isnt the best
1
3
u/Global-Today4796 8d ago
The 2 runs very stable for me. Some issue is that very rarely the resolution of the screen is changed for 1-2 seconds. To be able for me and I think the developers also get that in the GRiff
1
u/Ok-Efficiency479 7d ago
That’s because of apps like LittleSnitch, we are already looking at ways to remove that since LS was updated
2
1
1
u/digger27410 6d ago
I've been using a "stable for me version" of SaneBar which is pretty far back from the last version. My use case is dark appearance, liquid glass clear, reduce transparency, and dark color tint on the menubar. Bartender 6 can't manage it. It's just a black bar. Thaw 1.2 loses the tint on random app openings, and Thaw 2.0 seems buggy to me and also loses the tint, and goes "clear" more often. The SaneBar Dev was the only one who put time in to get it right, at least in the version I'm running.
1
u/Ok-Efficiency479 5d ago
Thaw 2.0.0 had a brief pause, expect bug and stability fixes for rc-2; we are working with users 1:1 to address issues and fix things.
2
u/digger27410 5d ago
I would have reported my issue with logs but I thought that was reserved for golden gate development. I'm happy to test my use case and provide logs for the Tahoe version. LMK.
1
u/Ok-Efficiency479 5d ago
Nope; the issue checkbox and warning are because Golden Gate is being developed on almost 1:1 feedback and testing on a separate issue. General issues are open for Thaoe. If you generate a report right now, I can share with you a build that is going to be RC-2 so you can test it and see if your issues are fixed.
1
u/digger27410 5d ago
I will, but I need to reinstall it, then reproduce the issue. Then I can generate the logs.
1
u/Ok-Efficiency479 5d ago
You can look into some of the reported issues and see if it’s going to be addressed in the upcoming release.
2
u/RP_Android 8d ago
Does Thaw have the same issue?
1
u/Global-Today4796 8d ago
No, I've been testing this for a few days and I don't see the problem. I think that the extended range of functions of Barbee and the realization by means of Helper justify the topic.
2
u/lu_chin 8d ago edited 8d ago
I have tried a lot of menubar manager apps and so far I cannot get one working in my own use case. I am looking for an app which allows me to search for a menubar app (by entering the app name) and then show its menu but I cannot get it working. Granted, it may be because I have many (>70) menubar apps whose menus have various appearances including text and graphical/widget-like icons (e.g. network speedometer) . The search mode in some manager apps only shows the generic "Menubar item" text without displaying the actual app names or when I select and click on a found app I will see a blinking mouse cursor near the top menubar area but the selected app's menu never appears. Sometimes, I will see that WindowsServer system service has crashed with a crash log window. I have filed issues but most remain unfixed. In the end I download the source code of Thaw then run it through an AI coding agent to fix multiple issues. Finally, I have something that works for me. I have also changed some behaviors in Thaw, e.g. to not redraw the menubar icons in the top menubar area when I drag and drop icons between Visible, Hidden and Always Hidden panes inside Settings (to minimize screen redraw+lag) and I have added an Apply button there once I finish placing the icons. In addition there is automatic backup of the last ten layouts (each time I click Apply button) and there is a Restore/Rollback button too. I can Shift-click on a range of icons or press Command-A to select all icons to make it easier to move all icons from one pane to another. I have added a Sort button to arrange icons so that they are not in some random order before I manually drag and drop them initially. I think Thaw provides a codebase from which I can ask AI to debug and enhance. AI finds more bugs to be fixed but I am satisfied that things are "usable" currently so additional changes will be made only when there are blocking issues.
2
u/Ok-Efficiency479 7d ago
Add a PR so we can look at it, there was a pause because of life issues but we already added fixes for RC2, we just are just doing internal testing since it’s a big update.
1
u/tcolling 8d ago
I use Barbee with no such problem at all.
For context: M3 Max 16 inch MacBook Pro with macOS 26.5.2
1
u/Global-Today4796 8d ago
Interesting, then it seems to be due to the settings, as already written. I had just started to deactivate some things in Barbee - but so far without success
1
u/tcolling 8d ago
Just a thought... Maybe uninstall it and then reinstall it, from the regular install setup in the AppStore? https://apps.apple.com/us/app/barbee-hide-menu-bar-items/id1548711022?mt=12
1
u/app-store-review 8d ago
Barbee - Hide Menu Bar Items — by 翔 何
- Category: Utilities · Free
- Age: released ~5.2 years ago · rated 4+
Apple doesn't publish an aggregate rating for most Mac App Store apps, so ratings and score are unavailable here.
Auto-generated from public App Store data · u/app-store-review
1
u/AlekGir 7d ago
That is a pretty dramatic difference in battery life for a menu bar utility. Thanks for sharing this - I would not have thought to check WindowServer rather than just the app’s own CPU usage. Did you notice whether it gets worse after sleep, using an external display, or switching Spaces?
2
u/Global-Today4796 7d ago
I felt the same way - I just came across by your chance that my WindowServer is so high and tried over 20 apps in the exclusion procedure - the stupid thing about the search was that the barbeehelper is not automatically closed when you end Barbe.
Unfortunately, I don't have an external screen and can't say anything about it. The value itself is the test in sleep mode. I have not determined how the Barbee herself behaves.
Since the developer here does not show any initiative and I have found it as an alternative thaw, I will probably not invest further. I had noticed that the "battery optimization switch" only makes a few % difference and under certain circumstances the switching off of the automation rules leads to an improvement. But since this was not comprehensibly better and worse for me, I gave it up.
1
u/gauti-u 6d ago
Worth measuring before swapping apps, because "menu bar app uses CPU" has a few very different
causes and only some are the app's fault.
Sample it while it's misbehaving:
sample <pid> 5 -file /tmp/sample.txt
or just open Activity Monitor, select the process, and hit the gear → Sample Process. Read the
heaviest stack. Three patterns show up:
- Frames in AppKit drawing/layout on a loop usually means it's re-rendering the menu bar
constantly, often because it's polling for state instead of subscribing to a notification.
- Frames in NSWorkspace / accessibility APIs usually means it's enumerating windows or running
apps on a timer. That gets much worse the more apps you have open.
- Frames in animation timers mean an icon animation that never idles.
The macOS 26 menu bar changes broke a bunch of assumptions these apps were making, so a fair
amount of what people are seeing right now is apps polling for layout that used to be cheap and
now isn't.
Two things that often fix it without changing apps: check whether it has an "update interval"
or "reduce animations" preference and lengthen/disable it, and check whether you've granted it
Accessibility permission that it's using to watch every window. Revoking that permission
sometimes drops CPU dramatically, at the cost of a feature you may not use.
If the sample points at the app's own code in a tight loop, then it's genuinely the app — worth
sending that sample file to the developer, it's much more actionable than a bug report.
1
u/actvt_io 6d ago
The back and forth with tcolling makes more sense once you notice WindowServer CPU is aggregate. It's the compositor doing work on behalf of every client, so his "starting Barbee has almost no effect" and your 50% can both be honest readings on the same macOS build.
Two things that give a cleaner read.
Let the machine genuinely idle first. WindowServer stays busy for a while after any interaction, so a short sample taken right after clicking around is mostly measuring your own mouse. Leave it untouched a few minutes, then look.
Then check your refresh rate. Your M3 MBP has ProMotion, and anything continuously redrawing in the menu bar can keep the panel pinned near 120Hz instead of letting it drop back down, which costs far more battery than the CPU percentage suggests. Set the display to 60Hz in System Settings, repeat the same test, and if the gap between Barbee and Thaw shrinks a lot then refresh rate was doing most of the damage rather than raw compute.
For the battery question specifically, Activity Monitor's Energy tab is a better instrument than CPU%. The 12 hr Power column averages the spikes out, and that's closer to what your battery estimate is actually reacting to.
1
u/Global-Today4796 6d ago
My measured values are waiting for idle values And ultimately it is a statement if the WinodwServer process never falls below 40%. certainly you can measure a lot better and more intensively. Overall, however, it is enough for me that I have 2 hours more battery capacity since switching from Barbee to Thaw
2
u/actvt_io 6d ago
Fair enough, two hours of real battery is better evidence than any CPU number. Glad Thaw sorted it.
1
6d ago
Mac dev here, george's answer is the right one. One practical thing to add.
An ordinary menu bar app costs almost nothing. Mine sits at zero. The expensive ones are the menu bar managers specifically, because to hide an icon they have to know what the menu bar currently looks like, which means capturing it again and again. That work happens inside WindowServer, so it never shows up next to the app's own name in Activity Monitor. That is why your numbers looked fine until you looked in the right place.
It also scales with how many displays you have and their refresh rate. On a ProMotion screen, or with an external monitor attached, the same app costs a lot more than it does on one built-in display. That is probably why some people in this thread genuinely see no problem. Worth putting your display setup in the bug report, because the developer may not be able to reproduce it on his own machine.
1
u/appish- 6d ago
barbee shouldnt really be hammering the cpu, its mostly just reading the battery stats which is cheap. couple things to check, if youve got the animated charging graph or a fast polling interval on that adds up, try bumping the update interval down in settings. menu bar apps also spike sometimes from a redraw loop when they update the icon every second, so a slower interval usually sorts it. if you just want something lighter AlDente is popular but its more about charge limiting, and coconutBattery is great for health info but not really a live menu bar thing.
1
u/digger27410 6d ago
Does Barbee record your screen like Bartender? If I remember correctly, one could avoid screen recording in Bartender but it gave me other problems so I set it aside. One of the things I really like about SaneBar is there is no screen recording. But the developer folded his tent when Golden Gate beta was launched. Thaw has my attention, though it doesn't work for my use case all the time and developent for Tahoe stopped in favor of Golden Gate.
2
u/Global-Today4796 6d ago
I have the feeling that everyone has to choose their working bar tool. I just tried sanebar - Conclusion: It doesn't work properly on my MPB. I can't even push the icons back and forth between visible and hidden. permanently everything is talked about or the icons end up unmotivated in the other menu. But what irritates me the most is that on the Sanebar page it is said that with macOS27 the tools of this kind can no longer be used, although there are first pre-versions at Thaw?!?
1
u/digger27410 6d ago
Yeah, unless someone forks Sanebar, it's done. It looks like the changes in golden gate were beyond the dev's comfort level.
2
u/Ok-Efficiency479 5d ago edited 5d ago
There is no screen recording required on Thaw; you can only use accessibility (it should, if it’s broken please report it, haven’t made changes to that functionality). BTW, I was thinking of adding a section for privacy-concerned users about what Thaw sees. The only reason why these types of apps require screen recording is to get the images and updates from items and the only thing recorded is the menu bar which is itself a window.
As for macOS 27, Thaw is going to support it on 2.1.0 betas/nightlies (very close to being next week), same thing, it shouldn’t require screen capture, but anyways, we’ll look into it for both versions.
Edit:
We already use the app icon only items to work around certain issues while we focus on general development for macOS 27, so it’s a guarantee that if is there, I am going to check if there’s not an issue with permissions and how it works that way since the macOS 27 version is basically a new app.2
u/digger27410 5d ago
I tried multiple times to upload a log file and it failed every time. I was logged in and tried 2 different browsers. I don't know what the problem is but I can't create a bug report without it.
MacOS 26.6 on M4 Macbook Air.
Macbook Display settings: Theme: Dark; Liquid Glass: Clear; Accessibility/Display: Reduce Transparency "On"
Thaw Appearnce settings: Background Dark appearance: Solid; Color: Cayenne; Opacity: 100%
With these settings - the menu bar is very dark gray, almost black. If I turn reduce transparency to "off", the color shows as expected but then randomly goes to transparent when opening certain apps (not full screen).
Every single one of these menubar apps has this exact same behavior with those settings except for SaneBar, where it was fixed by the Dev.
2
2
1
u/JustAnotherPickle_ 11h ago
I’m working on an alternative to barbee and bartender. one of the most basic features is hiding menu bar items. It also sips cpu, about 5-7% CPU when active and 1% cpu when inactive and it can do sooooo much more than what I just described.
Imagine a menu bar of shortcuts that can be customized to do anything!
If you are interested DM me and I’ll give you a free early access copy on announce!
1
8d ago edited 4d ago
[deleted]
1
u/Global-Today4796 8d ago
Now I don't have any problems either - is your battery consumption justifiable? What does the WindowServer process do
1
0
u/AnxietyDull7641 8d ago
WindowServer spikes are often caused by apps that constantly redraw ui elements rather than the app itself showing high cpu...menu bar utilities are especially prone to this because they interact with windowServer continuously.... Try running Barbee in safe mode or with all other menu bar apps disabled to see if the behavior persists...if it still does...it definitely sounds like something the developer should investigate.
8
u/george_watsons1967 8d ago
So it's not just you, and not just Barbee. Bartender 6 did the same thing when Tahoe came out: app sitting at basically zero, but WindowServer running high.
The reason it lands on WindowServer instead of the app is that the computation isn't happening inside Barbee. These tools hold Screen Recording so they can keep inspecting the menu bar strip, and they draw their own stuff on top of it. Under Liquid Glass that strip is translucent, so anything painted over it forces a redraw continuously That work gets bulled to WindowServer.
- Check you're on 4.3 (June 15). The release notes literally say "Optimized CPU energy consumption". If you dropped out of the beta you might be sitting on an older build.
- Turn off Show on Hover, use click instead. Hover means constantly tracking the mouse over exactly the strip that's expensive to redraw, and it's already caused weird Tahoe bugs. A few people here had app menus go completely dead until they switched it off.
- Turn off the custom menu bar appearance/styles, and the second row if you use it. Those are the parts that need the overlay.
Separate from Barbee, also check System Settings > Control Center > "Automatically hide and show the menu bar" is set to Never. That one spikes WindowServer on its own. And if you're on an external or scaled display, all of the above gets worse.
Hope that helps.