mirror of
https://github.com/JakeStanger/ironbar.git
synced 2026-07-11 08:15:21 +01:00
[GH-ISSUE #1467] CPU Performance Regresson #8875
Labels
No labels
A:Build
A:CI
A:Client
A:Config
A:Core
A:Documentation
A:Documentation
A:IPC
A:Testing
A:UX/UI
blocked
BREAKING CHANGE
duplicate
good first issue
GTK4
help wanted
invalid
M:Battery
M:Battery
M:Bindmode
M:Bluetooth
M:Brightness
M:Cairo
M:Clipboard
M:Clock
M:Clock
M:Custom
M:Focused
M:Keyboard
M:Launcher
M:Menu
M:Music
M:Music
M:Music
M:Network Manager
M:Notifications
M:SysInfo
M:Tray
M:Volume
M:Workspaces
partially resolved
P:Critical
P:High
P:Low
P:Medium
pull-request
T:Bug
T:Bug
T:Core Enhancement
T:Module Enhancement
T:New Module
T:Question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
JakeStanger/ironbar#8875
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @CameronBarnes on GitHub (Apr 25, 2026).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/1467
Describe the bug
In prior versions, ie 0.18, CPU usage for ironbar on my system sits around 0% the vast majority of the time. Building and running the latest version from github consistently shows a CPU usage of what appears to be between 8-17% across all 16/32 cores/threads of my 7950x.
Git bisect has narrowed down the cause of the problem to the following commit
2cb9288980This appears to me to be unrelated to #1425, as this issue occurs consistently and immediately when running ironbar.
To reproduce
Steps to reproduce the behavior:
Expected behavior
Previously CPU usage of ironbar was near 0, definitely preferable for my taskbar to not be holding my CPU at a constant 60C
System information:
742fe7f4f1Configuration
Config
Styles
Additional Info
I did a flamegraph and saw what appears to be an abnormal amount of signaling and hash related functions going on. But I honestly havent used flamegraphs that much and may have setup either the known good or the bad state run incorrectly or just misread the results.
@JakeStanger commented on GitHub (Apr 25, 2026):
Hm, I fixed that regression recently, or so I thought.
github.com/JakeStanger/ironbar@7210ad767cI know it sounds silly but could you double check you're definitely experiencing the issue on commits past that please?
@CameronBarnes commented on GitHub (Apr 25, 2026):
Huh. I was pretty sure that I had tried manually building directly from master. But doing so now appears fine. It's possible that I was expecting ironbar-git from the aur to actually be the latest commit. I suppose I'm liable to make mistakes like that when frustrated at 2am. My apologies for the inconvenience here.
I've cargo installed directly from git so I shouldnt make that mistake again.
@JakeStanger commented on GitHub (Apr 25, 2026):
No worries, glad to hear it is sorted. The AUR package should pull the latest commit, although depending on your aur helper you might sometimes need to sync the database or give it a kick to behave.
@CameronBarnes commented on GitHub (Apr 25, 2026):
It doesnt help that at the time the AUR was down because it's getting DDOS'd again right now.