High CPU usage

[pigmej]

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]

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]

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]

gymore-io/winput#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]

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]

I have tried forking winput to 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.

Jonesey13/multiinput-rust#2 the multiinput repo 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:

• Only start the message loop when custom FFM has been explicitly enabled
• Destroy the message loop whenever custom FFM is disabled

[LGUG2Z]

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 komorebi using those libraries as a guideline so that I can have finer control of the message loop lifecycle.

[pigmej]

I can confirm that disabling completely mouse tracking helps a lot with CPU cycles ;) komorebi is pretty much using 0% CPU now.

[LGUG2Z]

@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]

@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 the rustc compiler 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]

@LGUG2Z sorry lost windows machine for a while ;/ I don't have a way to test it now.