Extremely High CPU Usage!

[joepetrillo]

Running on macOS Big Sur 11.0.1 (20B29)

Whenever eul is open, my cpu usage spikes to 100% (somehow 199% in screenshot) and stays there indefinitely. Fans get super loud as a result.

[mikield]

Can confirm on my machine too.

UPD: Very strange behavior. Restarting the program helped.

UPD2: Eul jumps to more 100% CPU usage after unchecking one of this checkboxes. (I think "Show network top activities")

And only by unchecking it, all is good after turning that on again.

[gao-sun]

@joepetrillo @mikield thanks for feedback. will take a look soon

[IoannisTM]

same here, as @mikield mentioned

[AyoubOuarrak]

Same here on Big Sur 11.0.1 (late 2013 MacBook Pro)

[gao-sun]

a quick update, I'm too busy on my daytime work these days, did not get a chance to take a look at this issue. I'll try tonight/tomorrow

[gao-sun]

added several improvements in v1.4.4, please try and let me know if it helps

[IoannisTM]

seems to work fine for me. will update if again as now I have 1.4.5 running. nice

[Davedeji]

still somewhat having issues with this. eul spikes to 50-65 percent cpu usage when idle (just in the menu bar updating). as soon as you click on the menu bar icon to show full stats, it drops to about 1-1.5 %. Using a MBP 16" 2019.

Edit: After messing around a bit more it seems to be related to showing components in status bar, when that is turned off, it goes back to using ~1% of cpu

[TheBreznsoiza]

I see since v1.4.4. a lot of red EUL (no response) in the activity monitor, same on v1.4.5. When I try to open the eul settings the app freezes and beach balling all the time, after 10-20 seconds, I can click again somewhere a beach balling happens again... Was before better as I can remember

Another annoying thing after a reboot I see also a popup that "some parts of eul are hidden by the system (bartender 4) and click on one of the buttons the app freezes again.

Using it on a Mac mini M1 and MacBook Pro 15" (2017)

[gao-sun]

@Davedeji @DasBlatz would you mind to use debug mode and paste some output here? say you have eul in /Applications folder, then open terminal and run

/Applications/eul.app/Contents/MacOS/eul --debug

[gao-sun]

@DasBlatz I have no macOS on M1 for now - I believe some parts of eul are not compatible with the new chip since some SMC calls may be hardware-sensitive. spent too much money these days (RTX 3080 & the new iPhone), will try to buy one in early next year (if get enough pay). stay tuned. cheers

[Davedeji]

@gao-sun Here you go.

---

⚙️ loaded data from user defaults preference { "smcRefreshRate" : 3, "textDisplay" : "compact", "temperatureUnit" : "celius", "fontDesign" : "default", "showNetworkTopActivities" : true, "networkRefreshRate" : 5, "showCPUTopActivities" : true, "language" : "en", "showIcon" : true } 🔋 battery info 100 100 0 0 true false good acPower 🔋 battery info 100 100 0 0 true false good acPower ⚙️ loaded data from user defaults EulComponent { "showComponents" : true, "activeComponents" : [ "CPU" ], "availableComponents" : [ "Network", "Disk", "Battery", "Fan", "Memory" ] } ⚙️ loaded data from user defaults EulMenuComponent { "availableComponents" : [

], "showComponents" : true, "activeComponents" : [ "Battery", "CPU", "Memory", "Fan", "Network" ] } shell with ["route get 0.0.0.0 | grep interface | awk \'{print $2}\'"] shell with ["netstat -bI en0"] ⚙️ loaded data from user defaults componentConfig { "configs" : [ { "showIcon" : true, "showGraph" : false, "component" : "Network" }, { "showIcon" : true, "showGraph" : false, "component" : "Disk" }, { "showIcon" : true, "showGraph" : false, "component" : "Fan" }, { "showIcon" : true, "showGraph" : false, "component" : "CPU" }, { "showIcon" : true, "showGraph" : false, "component" : "Battery" }, { "showIcon" : true, "showGraph" : false, "component" : "Memory" } ], "converted" : true } ⚙️ loaded data from user defaults CpuTextComponent { "showComponents" : true, "availableComponents" : [

], "activeComponents" : [ "usagePercentage", "temperature" ] } 🔋 battery info 100 100 0 0 true false good acPower shell with ["diskutil apfs list -plist"] shell with ["route get 0.0.0.0 | grep interface | awk \'{print $2}\'"] shell with ["netstat -bI en0"] ✅ status item is visible 🔋 battery info 100 100 0 0 true false good acPower shell with ["diskutil apfs list -plist"] shell with ["route get 0.0.0.0 | grep interface | awk \'{print $2}\'"] shell with ["netstat -bI en0"] 🔋 battery info 100 100 0 0 true false good acPower shell with ["diskutil apfs list -plist"] shell with ["route get 0.0.0.0 | grep interface | awk \'{print $2}\'"] shell with ["netstat -bI en0"] 🔋 battery info 100 100 0 0 true false good acPower shell with ["diskutil apfs list -plist"]

[gao-sun]

@Davedeji will take a look

[gordio]

I can't understand how all project work. But trying to research problem. And looks like problem in Combine or "delegate handling". Also found if open "details window" - CPU overload is gone. Problem not in NetworkUpdate, checkVisibilityIfNeeded, icons refresh/render, I think…

[gordio]

Unfortunately I can't reproduce that issue anymore. But that's what I manage to catch…

[gao-sun]

@gordio thank you so much so detailed feedback!! sorry i missed your message. according to this call stack. i think the problem may caused by the combination of SwiftUI and NSStatusItem, or the way i'm trying to refresh/resize the view. hard to know what was wrong but will try to go deep on this. let me know if you can re-produce this stably

[nmcdonaldd]

@gao-sun I have an app with a similar NSStatusItem-related performance issue as well related to Core Animation on Big Sur. I can consistently reproduce it only when using a light wallpaper. If the user's wallpaper is sufficiently light-enough such that the status bar must use dark text on a lighter background, there's a huge uptick in CA::Transaction::commit() calls. If, however, you use a wallpaper which forces the status bar into its "darker" mode (light text) then there's no issue.

You can consistently reproduce this with the provided wallpapers (Big Sur Graphic vs Big Sur Day). To show that this is not a consequence of this app, I've written my own demo app which illustrates the CA bug. It simply puts text inside a SwiftUI-implemented custom view inside an NSStatusItem's button (my app I first noticed this on uses a much more complex view, but this shows the issue).

Furthermore, here's a video showing the huge drop off in CPU usage when switching between a wallpaper which changes the status bar's background from light to dark. Notice the huge drop-off in CPU usage.

I've reported this to Apple (<-- not sure if that's shareable) and also asked on the Apple Developer Forums, but had no luck so far. I'll keep you updated on this since, as mentioned, I'm also seeing it on my own personal project and I don't think there's anything we as developers can do to mitigate this right now.

[lkhphuc]

Today I woke up to my Macbook fan spinning at full speed, while it's sleeping. When I turn it on and open activity monitor, Eul is the culprit with 100% cpu. What even more weird is that I have the status line component disabled already and I only used Eul for its widgets. Edit: Powernap is unchecked as in the image belows.

[gordio]

… while it's sleeping …

Check this please.

[gao-sun]

@nmcdonaldd thank you. your reproduction looks convincing. thank you for reporting to apple and feel free to let me know if there's anything i can help with

[dawulf]

I installed eul a couple hours ago and I'm getting 100-200% CPU usage. I'm on a M1 MacBook Air (2020). Problem persists after unchecking all of the Show CPU/RAM/network top activities boxes. Restarting the app gets rid of the problem, but at some point soon after restarting, even when restarting with settings that don't show network or network top activities, CPU jumps to 100% and then to 200%. That process does seem to happen quicker when network top activities is checked, but that could be random.

[bluemix]

sometimes, I am getting the same issue

[gao-sun]

@dawulf @bluemix i think a possible cause is i was using sync mode to execute some scripts, which may block the normal UI rendering. i'm trying to migrate them all to async mode.

[arastu]

@gao-sun This problem has sometimes occurred even in v1.6, The CPU usage has increased by 30% to 60% on my 2019 MacBook Pro (macOS 11.4, intel based).

[AllenX-Li]

Same problem here occasionally happens on my Macbook Pro 2018

[soer7022]

Also happens on my MacBook Pro 2016 15"

[gao-sun]

i noticed this issue as well, but i cannot stably reproduce. :headache: i'm going to open Xcode, start debugging and wait for awhile until the cpu usage is getting higher. or it'll be great that someone can provide a way to reproduce.

[osh123]

@gao-sun eul is getting 100% in my system right from the start, all the time. If you need help in debugging this, ping me

[strfn]

+1 have to stop using Eul for the same reason unfortunately.

[thebadpete]

For me it always happens regardless of versions, always 100% cpu from activity monitor. I am not a Mac developer but I would like to help (I have XCode), please let me know

[gao-sun]

@osh123 @thebadpete thanks for willing to help. i need either a way to stably reproduce or some debug info. one thing you can do is

Step 1. clone this project

Step 2. open xcode and wait for dependency tasks are done

Step 3. click the "play button" in the top left corner to build and run eul

Step 4. switch to "debug navigator"

Step 5. click "CPU"

Step 6. take some screenshots on this page

Step 7. click "Profile in Instruments" note: either "Profile" or "Restart" is ok once you can record and observe the 100% CPU issue.

Step 8. record for a while, then stop once you think is enough, and save the trace file.

you can pack the results of step 6 and 8 to zip then upload here. that will be very helpful!

[ghost]

+1 And sometimes eul will quit in slience on my mac.

[thebadpete]

Sorry @gao-sun I totally missed your message, but I would like to report that eul seems to behave fine on MacOS to Monterey (12.0.1)! No more 100% CPU! I recently upgraded my MacOS, and I tried eul again (version v1.6.2). It is the same binary that exhibited issues on MacOS Big Sur.

Just some happy data point to report. For those who had the same 100% CPU issue, give MacOS Monterey a try!

[AltriaOwO]

Dear developer: As the pic shows, this is what happened on my MacBook Pro

MacBook Pro (13-inch, 2017) CPU: Intel Core i5-7267U System Info: macOS Monterey 12.3.1

[yarub123]

Unfortunately same here. From 200-300% CPU usage. (That's without the menu even open.)