个人效率Reddit 原帖

Barbee consumes too much CPU?

完整上下文原始内容 · Reddit

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

01需求标签
个人效率产品替代桌面应用已有产品解决

已收集讨论

25 条已收集

25条已收集35条 Reddit 标称评论
u/george_watsons1967

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.

u/Global-Today4796楼主回复

Thank you very much - I will try that (4.3. I already use) - but she said Thaw does not have this problem according to my experience

u/Global-Today4796楼主

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%

u/jlext

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.

u/Global-Today4796楼主回复

Try Thaw for free, you can search for elements

u/Daventurephoto

I agree, Barbee was no good, and Bartender has let us modern Mac users down. I was using Sanebar for a bit alongside Bartender, which seemed to help the issue slightly, but it was too overloaded. For a few months, I’ve also been using Thaw, but holding back to version 1.2.0. How is version 2.0? Are there any issues that you have noticed?

u/Global-Today4796楼主回复

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

u/Ok-Efficiency479回复

That’s because of apps like LittleSnitch, we are already looking at ways to remove that since LS was updated

u/tcolling回复

I respectfully disagree with you about Barbee. Barbee is actually quite good and works well for me and many others.

u/Global-Today4796楼主回复

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%?

u/tcolling

I use Barbee with no such problem at all. For context: M3 Max 16 inch MacBook Pro with macOS 26.5.2

u/Global-Today4796楼主回复

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

u/tcolling回复

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

u/Global-Today4796楼主回复

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.

u/AlekGir

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?

u/Global-Today4796楼主回复

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.

u/scottjl

Weird. I’ve been using Barbee years now and never had an issue.

u/Global-Today4796楼主回复

Now I don't have any problems either - is your battery consumption justifiable? What does the WindowServer process do

u/scottjl回复

I have a 5 year old MBP M1. No issues with battery drain, WindowServer 1% or less. I dumped Bartender after the buyout. I've tried Ice, Thaw, iBar, Hidden Bar, and a half-dozen apps that manage the menu bar as an extra feature. I keep coming back to Barbee.

u/Global-Today4796楼主回复

Yes, as I said, it works much more performantly

u/lu_chin

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.

u/Ok-Efficiency479回复

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.

u/gauti-u

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.