High CPU usage #30

New Issue

2026-01-05T14:47:47+01:00

adam commented

2026-01-05 14:47:47 +01:00

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?

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?

adam added the performance label 2026-01-05 14:47:47 +01:00

adam closed this issue

2026-01-05 14:47:47 +01:00

adam commented

2026-01-05 14:47:48 +01:00

@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): The culprit for the increased CPU usage is [here](https://github.com/LGUG2Z/komorebi/blob/master/komorebi/src/process_movement.rs#L17). I will open an issue on the [winput](https://github.com/gymore-io/winput) repo and also explore other alternatives for listening to mouse events in the meantime.

adam commented

2026-01-05 14:47:48 +01:00

@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): If you're not interested in focus-follows-mouse, you can compile with [this line](https://github.com/LGUG2Z/komorebi/blob/master/komorebi/src/main.rs#L232) commented out and you should see the CPU usage drop dramatically.

adam commented

2026-01-05 14:47:48 +01:00

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

@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](https://github.com/gymore-io/winput/issues/1#issuecomment-809270264), so perhaps this might help.

adam commented

2026-01-05 14:47:48 +01:00

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

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

adam commented

2026-01-05 14:47:48 +01:00

@LGUG2Z commented on GitHub (Sep 14, 2021):

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.

https://github.com/Jonesey13/multiinput-rust/issues/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 commented on GitHub (Sep 14, 2021): I have tried forking `winput` to listen to just mouse events, and I have also tried swapping it out for [multiinput](https://github.com/Jonesey13/multiinput-rust) 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 `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

adam commented

2026-01-05 14:47:48 +01:00

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

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

adam commented

2026-01-05 14:47:48 +01:00

@pigmej commented on GitHub (Sep 15, 2021):

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

@pigmej commented on GitHub (Sep 15, 2021): I can confirm that disabling completely mouse tracking helps a lot with CPU cycles ;) `komorebi` is pretty much using 0% CPU now.

adam commented

2026-01-05 14:47:48 +01:00

@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 (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.

adam commented

2026-01-05 14:47:49 +01:00

@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 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. 🚀

@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 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. 🚀

adam commented

2026-01-05 14:47:49 +01:00