search

nwg-piotr / nwg-dock

GTK3-based dock for sway
MIT License
173 stars 9 forks source link

High CPU utilisation #24

Closed haselwarter closed 2 years ago

haselwarter commented 2 years ago

I'm running nwg-dock 0.2.2 from AUR on Arch with sway from git (sway 1.8-dev-cd1ee0e1) on a recent laptop, and nwg-dock constantly uses about 10% of CPU.

nwg-dock -debug doesn't show anything suspicious.

I'm using Go and gtk-layer-shell versions 2:1.17.6-2 and 0.7.0-1 respectively.

nwg-piotr commented 2 years ago

How did you measure this value? At the moment I'm running residently the dock, nwg-drawer and nwg-panel, and my CPU usage oscillates between 1.3 and 1.8%, with 3 active 1920x1080 outputs.

haselwarter commented 2 years ago

I'm just looking at htop, one 4k output. Plugged in my external monitor, 2k, turned off the internal one (swaymsg output eDP-1 disable), still the same CPU usage :/

haselwarter commented 2 years ago

By the way, I just noticed that nwg-drawer is similarly cpu hungry. Doesn't matter whether I start it with -r or not. Let me know if there's debugging I can do.

nwg-piotr commented 2 years ago

What you see in htop are momentary values, that have few to do with the real cpu load. If I open htop in Alacritty at the moment, I'll see values up to 7% for nwg-drawer and even up to 35% for Chromium, while the real average CPU load is up to 3%.

image

haselwarter commented 2 years ago

I'm not sure how to break this down more without reading the source and debugging nwg-drawer, but there certainly is a problem. htop is crude, sure, but it gives you an idea. You don't seem to be convinced, so let's run a few programs for 60 seconds and see how much CPU time they use up.

time timeout 60 nwg-dock -d -w 10 -nows
INFO[0000] Starting in autohiDe mode
INFO[0000] Using auto-detected launcher command: 'nwg-drawer'
INFO[0000] Using style: /home/philipp/.config/nwg-dock/style.css
INFO[0059] SIGTERM received, bye bye!
timeout 60 nwg-dock -d -w 10 -nows  2.16s user 1.82s system 6% cpu 1:00.00 total
time timeout 60 src/Waybar/build/waybar
timeout 60 src/Waybar/build/waybar  0.25s user 0.06s system 0% cpu 1:00.03 total
time timeout 60 google-chrome-stable
timeout 60 google-chrome-stable  3.85s user 0.83s system 7% cpu 1:00.04 total

So nwg-dock consumes an amount of CPU time comparable to a web browser, while waybar does almost no work. Running nwg-dock for a shorter amount of time (say 10s) leads to a proportionally lower amount of cpu time, so it's not about doing some setup work in the beginning, instead it keeps running.

nwg-piotr commented 2 years ago

See https://github.com/nwg-piotr/nwg-drawer/issues/50. This is likely to find an application here as well.

Raffy23 commented 2 years ago

It seems that nwg-dock has a similar bug as the nwg-drawer, which causes the high cpu load (https://github.com/nwg-piotr/nwg-dock/blob/main/main.go#L551-L562). I can prepare a PR similar to the one for the nwg-drawer later this week to solve this problem.

nwg-piotr commented 2 years ago

I can prepare a PR similar to the one for the nwg-drawer later this week to solve this problem.

Sure, I am always open to good PRs.

Raffy23 commented 2 years ago

I have started on a patch for the issue, but it turns out to be a little bit more complex. Not only is the USR1 signal polled, but also the window list of sway. I managed to reduce the CPU load to 0% in on my branch, but currently the dock will not update if any modifications are performed. I think that without restructuring a lot of code every addition will be way more hacky then what I did ...