mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-01-11 14:40:25 +01:00
High CPU usage #30
Reference in New Issue
Block a user
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 @pigmej on GitHub (Sep 14, 2021).
Originally assigned to: @LGUG2Z on GitHub.
I found it out today, that running komorebi consumes 13% of one CPU core constantly.
Not sure how could I debug it any further. In the logs, there is nothing suspicious.
How could I help debugging that further?
@LGUG2Z commented on GitHub (Sep 14, 2021):
The culprit for the increased CPU usage is here. I will open an issue on the winput repo and also explore other alternatives for listening to mouse events in the meantime.
@LGUG2Z commented on GitHub (Sep 14, 2021):
If you're not interested in focus-follows-mouse, you can compile with this line commented out and you should see the CPU usage drop dramatically.
@LGUG2Z commented on GitHub (Sep 14, 2021):
https://github.com/gymore-io/winput/issues/1 It looks like I am already using the optimised version. 🙈
I'll try forking the library and seeing if it's possible to just listen to mouse events and ignore keyboard events. The author states
The problem comes from putting those events into the buffer.in this comment, so perhaps this might help.@pigmej commented on GitHub (Sep 14, 2021):
The thing is that I was observing that CPU usage even when stationary and "idling". That would make sense if there is some busy loop somewhere...
@LGUG2Z commented on GitHub (Sep 14, 2021):
I have tried forking
winputto listen to just mouse events, and I have also tried swapping it out for multiinput and only listening to mouse events there, but in both events the CPU usage is the same.https://github.com/Jonesey13/multiinput-rust/issues/2 the
multiinputrepo has a similar issue regarding high CPU usage which has also been addressed, which makes me think that with the APIs available, this is currently the performance price that must be paid for tracking and listening to mouse events in order to implement a custom focus follows mouse implementation.For
komorebi, it should only track the mouse when someone specifically enables FFM and even then, when they specifically opt for the custom implementation of FFM. The next steps that I will take are to:@LGUG2Z commented on GitHub (Sep 14, 2021):
Neither of the two libraries have any handlers for window destruction and class unregistering upon drop. I think I will implement the mouse event tracker from scratch in
komorebiusing those libraries as a guideline so that I can have finer control of the message loop lifecycle.@pigmej commented on GitHub (Sep 15, 2021):
I can confirm that disabling completely mouse tracking helps a lot with CPU cycles ;)
komorebiis pretty much using 0% CPU now.@LGUG2Z commented on GitHub (Sep 16, 2021):
@pigmej The custom FFM implementation is now explicitly opt-in via a command-line flag. If you just run
komorebic start, CPU usage should once again be <1%. The README has been updated to point out that enabling the custom FFM implementation comes with an additional CPU usage cost.@LGUG2Z commented on GitHub (Jul 25, 2022):
@pigmej Sorry to tag you in this blast from the past. Can you try enabling custom FFM again on the latest version of
komorebi? I think there must have been some improvements to therustccompiler that have resulted in better CPU utilisation in this case. I turned on custom FFM this morning to test something and the CPU usage is back at pretty much 0% for me now. 🚀@pigmej commented on GitHub (Jul 28, 2022):
@LGUG2Z sorry lost windows machine for a while ;/ I don't have a way to test it now.