[BUG]: Maybe a perf issue (high CPU &amp; fan speed) #399

Originally created by @KevinNitroG on GitHub (Jun 2, 2024).

Describe the bug

I think the version 0.1.26 has a performance issue. I have noticed many times that after using komorebi for a while, my computer's fan goes up and my CPU is about higher + 3-5%. It will end up by restarting komorebi (komorebi stop and then komorebi start), and the issue comes back after using for a while again.

To Reproduce

Steps to reproduce the behavior:

Use for a while (about > 30 mins)

Expected behaviour

No High CPU and Fan speed

Screenshots and Videos

In the video, we cannot see clearly the amount of CPU that komorebi took. But it affects my computer's CPU and Fan speed that I can feel it.

Operating System

OS Name:                   Microsoft Windows 11 Home
OS Version:                10.0.22631 N/A Build 22631

komorebic check Output

KOMOREBI_CONFIG_HOME detected: C:\Users\kevinnitro\.config\komorebi

Looking for configuration files in C:\Users\kevinnitro\.config\komorebi

Found komorebi.json; this file can be passed to the start command with the --config flag

Found C:\Users\kevinnitro\.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag

Additional context

I use AHK. There are few more unrelated config, but I just want to let you know for a more details analysis. My full AHK script is:

#SingleInstance Force

SetTitleMatchMode 3
DetectHiddenWindows true

; #Warn All, Off

; # Left Win
; ^ Ctrl
; ! Alt
; + Shift

#Include "komorebi/komorebic.lib.ahk"

; --- CONFIG ---

#Backspace::try ControlSend "!{F4}",, "ahk_class Progman"
^#!r::Reload

; --- RUN APP VIA KEYBOARD SHORTCUT ---

#Enter::Run "wt.exe"
#t::Run "alacritty.exe"
#c::Run "code.exe"
#b::Run "chrome.exe"
#s::Run "C:\Users\kevinnitro\AppData\Roaming\Spotify\Spotify.exe"

; --- ALT TO SWITCH TAB IN BROWSER ---

GroupAdd "Browser", "ahk_exe arc.exe"
GroupAdd "Browser", "ahk_exe brave.exe"
GroupAdd "Browser", "ahk_exe chrome.exe"
GroupAdd "Browser", "ahk_exe chromium.exe"
GroupAdd "Browser", "ahk_exe edge.exe"
GroupAdd "Browser", "ahk_exe firefox.exe"
GroupAdd "Browser", "ahk_exe thorium.exe"

#HotIf WinActive("ahk_group Browser")

!1::^1
!2::^2
!3::^3
!4::^4
!5::^5
!6::^6
!7::^7
!8::^8
!9::^9

#HotIf

; --- UNIKEY ---

#space::!z

; Cannot use bellow :v, UniKeyNT doesn't read the key
; #space::try ControlSend "!z",, "ahk_exe UniKeyNT.exe"

; --- KOMOREBI ---

#^o::ReloadConfiguration()
#^+r:: {
  try RunWait("komorebic.exe stop", , "Hide")
  RunWait("komorebic.exe start", , "Hide")
}

#1::FocusWorkspace(0)
#2::FocusWorkspace(1)
#3::FocusWorkspace(2)
#4::FocusWorkspace(3)
#5::FocusWorkspace(4)
#6::FocusWorkspace(5)
#7::FocusWorkspace(6)
#8::FocusWorkspace(7)
#9::FocusWorkspace(8)
#0::FocusWorkspace(9)

#[::CycleWorkspace("previous")
#]::CycleWorkspace("next")

#+1::MoveToWorkspace(0)
#+2::MoveToWorkspace(1)
#+3::MoveToWorkspace(2)
#+4::MoveToWorkspace(3)
#+5::MoveToWorkspace(4)
#+6::MoveToWorkspace(5)
#+7::MoveToWorkspace(6)
#+8::MoveToWorkspace(7)
#+9::MoveToWorkspace(8)
#+0::MoveToWorkspace(9)

#+[::CycleMoveToWorkspace("previous")
#+]::CycleMoveToWorkspace("next")

#Left::Focus("left")
#Down::Focus("down")
#Up::Focus("up")
#Right::Focus("right")
^#+[::CycleFocus("previous")
^#+]::CycleFocus("next")

^#+Left::Move("left")
^#+Down::Move("down")
^#+Up::Move("up")
^#+Right::Move("right")
^#p::Promote()

#+Right::ResizeAxis("horizontal", "increase")
#+Left::ResizeAxis("horizontal", "decrease")
#+Up::ResizeAxis("vertical", "increase")
#+Down::ResizeAxis("vertical", "decrease")

#w::ToggleFloat()
#m::Minimize()
#q::Close()
^#t::ToggleTiling() ; avoid with opening terminal
#z::ToggleMonocle()
; !Enter::F11 ; Toggle fullscreen
^#r::Retile()
^#+p::TogglePause()

^#h::Stack("left")
^#l::Stack("right")
^#k::Stack("up")
^#j::Stack("down")
^#;::Unstack()

#x::FlipLayout("horizontal")
#y::FlipLayout("vertical")

My full komorebi.json:

{
  "app_specific_configuration_path": "$Env:USERPROFILE/.config/komorebi/applications.yaml",
  "window_border": true,
  "border_style": "System",
  "border_colours": {
    "monocle": "#F9E2AF",
    "single": "#B4BEFE",
    "stack": "#CBA6F7",
    "unfocused": "#45475A"
  },
  "border_offset": -2,
  "border_width": 6,
  "cross_monitor_move_behaviour": "Insert",
  "default_container_padding": 0,
  "default_workspace_padding": 0,
  "manage_rules": [
    {
      "id": "Messenger.exe",
      "kind": "Exe"
    },
    {
      "id": "MicrosoftWhiteboard.exe",
      "kind": "Exe"
    }
  ],
  "float_rules": [
    {
      "id": "Authy Desktop.exe",
      "kind": "Exe",
      "matching_strategy": "Equals"
    },
    {
      "id": "Cloudflare WARP.exe",
      "kind": "Exe",
      "matching_strategy": "Equals"
    }
  ],
  "border_overflow_applications": [],
  "monitors": [
    {
      "workspaces": [
        {
          "name": "0",
          "layout": "BSP",
          "workspace_rules": [
            {
              "id": "arc.exe",
              "kind": "Exe"
            },
            {
              "id": "chrome.exe",
              "kind": "Exe"
            },
            {
              "id": "edge.exe",
              "kind": "Exe"
            },
            {
              "id": "firefox.exe",
              "kind": "Exe"
            },
            {
              "id": "opera.exe",
              "kind": "Exe"
            }
          ]
        },
        {
          "layout": "BSP",
          "name": "1",
          "workspace_rules": [
            {
              "id": "explorer.exe",
              "kind": "Exe"
            }
          ]
        },
        {
          "name": "2",
          "layout": "BSP"
        },
        {
          "name": "3",
          "layout": "BSP"
        },
        {
          "name": "4",
          "layout": "BSP"
        },
        {
          "name": "5",
          "layout": "BSP"
        },
        {
          "name": "6",
          "layout": "BSP"
        },
        {
          "name": "7",
          "layout": "BSP",
          "workspace_rules": [
            {
              "id": "obs64.exe",
              "kind": "Exe"
            },
            {
              "id": "obs32.exe",
              "kind": "Exe"
            }
          ]
        },
        {
          "name": "8",
          "layout": "BSP",
          "workspace_rules": [
            {
              "id": "vlc.exe",
              "kind": "Exe"
            },
            {
              "id": "Spotify.exe",
              "kind": "Exe"
            }
          ]
        },
        {
          "name": "9",
          "workspace_rules": [
            {
              "id": "Messenger.exe",
              "kind": "Exe"
            },
            {
              "id": "zalo.exe",
              "kind": "Exe"
            }
          ]
        }
      ]
    }
  ],
  "mouse_follows_focus": false,
  "resize_delta": 20,
  "window_hiding_behaviour": "Cloak",
  "$schema": "https://raw.githubusercontent.com/LGUG2Z/komorebi/v0.1.22/schema.json"
}

Originally created by @KevinNitroG on GitHub (Jun 2, 2024). **Describe the bug** I think the version `0.1.26` has a performance issue. I have noticed many times that after using komorebi for a while, my computer's fan goes up and my CPU is about higher + `3`-`5`%. It will end up by restarting komorebi (`komorebi stop` and then `komorebi start`), and the issue comes back after using for a while again. **To Reproduce** Steps to reproduce the behavior: 1. Use for a while (about > `30` mins) **Expected behaviour** No High CPU and Fan speed **Screenshots and Videos** In the video, we cannot see clearly the amount of CPU that komorebi took. But it affects my computer's CPU and Fan speed that I can feel it. ![Video](https://github.com/LGUG2Z/komorebi/assets/86353526/34d8c023-54bf-4050-995e-cb250e9a6f01) **Operating System** ``` OS Name: Microsoft Windows 11 Home OS Version: 10.0.22631 N/A Build 22631 ``` **`komorebic check` Output** ``` KOMOREBI_CONFIG_HOME detected: C:\Users\kevinnitro\.config\komorebi Looking for configuration files in C:\Users\kevinnitro\.config\komorebi Found komorebi.json; this file can be passed to the start command with the --config flag Found C:\Users\kevinnitro\.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag ``` **Additional context** I use AHK. There are few more unrelated config, but I just want to let you know for a more details analysis. My full AHK script is: ```ahk #SingleInstance Force SetTitleMatchMode 3 DetectHiddenWindows true ; #Warn All, Off ; # Left Win ; ^ Ctrl ; ! Alt ; + Shift #Include "komorebi/komorebic.lib.ahk" ; --- CONFIG --- #Backspace::try ControlSend "!{F4}",, "ahk_class Progman" ^#!r::Reload ; --- RUN APP VIA KEYBOARD SHORTCUT --- #Enter::Run "wt.exe" #t::Run "alacritty.exe" #c::Run "code.exe" #b::Run "chrome.exe" #s::Run "C:\Users\kevinnitro\AppData\Roaming\Spotify\Spotify.exe" ; --- ALT TO SWITCH TAB IN BROWSER --- GroupAdd "Browser", "ahk_exe arc.exe" GroupAdd "Browser", "ahk_exe brave.exe" GroupAdd "Browser", "ahk_exe chrome.exe" GroupAdd "Browser", "ahk_exe chromium.exe" GroupAdd "Browser", "ahk_exe edge.exe" GroupAdd "Browser", "ahk_exe firefox.exe" GroupAdd "Browser", "ahk_exe thorium.exe" #HotIf WinActive("ahk_group Browser") !1::^1 !2::^2 !3::^3 !4::^4 !5::^5 !6::^6 !7::^7 !8::^8 !9::^9 #HotIf ; --- UNIKEY --- #space::!z ; Cannot use bellow :v, UniKeyNT doesn't read the key ; #space::try ControlSend "!z",, "ahk_exe UniKeyNT.exe" ; --- KOMOREBI --- #^o::ReloadConfiguration() #^+r:: { try RunWait("komorebic.exe stop", , "Hide") RunWait("komorebic.exe start", , "Hide") } #1::FocusWorkspace(0) #2::FocusWorkspace(1) #3::FocusWorkspace(2) #4::FocusWorkspace(3) #5::FocusWorkspace(4) #6::FocusWorkspace(5) #7::FocusWorkspace(6) #8::FocusWorkspace(7) #9::FocusWorkspace(8) #0::FocusWorkspace(9) #[::CycleWorkspace("previous") #]::CycleWorkspace("next") #+1::MoveToWorkspace(0) #+2::MoveToWorkspace(1) #+3::MoveToWorkspace(2) #+4::MoveToWorkspace(3) #+5::MoveToWorkspace(4) #+6::MoveToWorkspace(5) #+7::MoveToWorkspace(6) #+8::MoveToWorkspace(7) #+9::MoveToWorkspace(8) #+0::MoveToWorkspace(9) #+[::CycleMoveToWorkspace("previous") #+]::CycleMoveToWorkspace("next") #Left::Focus("left") #Down::Focus("down") #Up::Focus("up") #Right::Focus("right") ^#+[::CycleFocus("previous") ^#+]::CycleFocus("next") ^#+Left::Move("left") ^#+Down::Move("down") ^#+Up::Move("up") ^#+Right::Move("right") ^#p::Promote() #+Right::ResizeAxis("horizontal", "increase") #+Left::ResizeAxis("horizontal", "decrease") #+Up::ResizeAxis("vertical", "increase") #+Down::ResizeAxis("vertical", "decrease") #w::ToggleFloat() #m::Minimize() #q::Close() ^#t::ToggleTiling() ; avoid with opening terminal #z::ToggleMonocle() ; !Enter::F11 ; Toggle fullscreen ^#r::Retile() ^#+p::TogglePause() ^#h::Stack("left") ^#l::Stack("right") ^#k::Stack("up") ^#j::Stack("down") ^#;::Unstack() #x::FlipLayout("horizontal") #y::FlipLayout("vertical") ``` My full `komorebi.json`: ```json { "app_specific_configuration_path": "$Env:USERPROFILE/.config/komorebi/applications.yaml", "window_border": true, "border_style": "System", "border_colours": { "monocle": "#F9E2AF", "single": "#B4BEFE", "stack": "#CBA6F7", "unfocused": "#45475A" }, "border_offset": -2, "border_width": 6, "cross_monitor_move_behaviour": "Insert", "default_container_padding": 0, "default_workspace_padding": 0, "manage_rules": [ { "id": "Messenger.exe", "kind": "Exe" }, { "id": "MicrosoftWhiteboard.exe", "kind": "Exe" } ], "float_rules": [ { "id": "Authy Desktop.exe", "kind": "Exe", "matching_strategy": "Equals" }, { "id": "Cloudflare WARP.exe", "kind": "Exe", "matching_strategy": "Equals" } ], "border_overflow_applications": [], "monitors": [ { "workspaces": [ { "name": "0", "layout": "BSP", "workspace_rules": [ { "id": "arc.exe", "kind": "Exe" }, { "id": "chrome.exe", "kind": "Exe" }, { "id": "edge.exe", "kind": "Exe" }, { "id": "firefox.exe", "kind": "Exe" }, { "id": "opera.exe", "kind": "Exe" } ] }, { "layout": "BSP", "name": "1", "workspace_rules": [ { "id": "explorer.exe", "kind": "Exe" } ] }, { "name": "2", "layout": "BSP" }, { "name": "3", "layout": "BSP" }, { "name": "4", "layout": "BSP" }, { "name": "5", "layout": "BSP" }, { "name": "6", "layout": "BSP" }, { "name": "7", "layout": "BSP", "workspace_rules": [ { "id": "obs64.exe", "kind": "Exe" }, { "id": "obs32.exe", "kind": "Exe" } ] }, { "name": "8", "layout": "BSP", "workspace_rules": [ { "id": "vlc.exe", "kind": "Exe" }, { "id": "Spotify.exe", "kind": "Exe" } ] }, { "name": "9", "workspace_rules": [ { "id": "Messenger.exe", "kind": "Exe" }, { "id": "zalo.exe", "kind": "Exe" } ] } ] } ], "mouse_follows_focus": false, "resize_delta": 20, "window_hiding_behaviour": "Cloak", "$schema": "https://raw.githubusercontent.com/LGUG2Z/komorebi/v0.1.22/schema.json" } ```

adam added the bug label 2026-01-05 14:50:23 +01:00

adam closed this issue

adam commented

@LGUG2Z commented on GitHub (Jun 2, 2024):

Can you try taking some measurements with a command line tool like https://github.com/ClementTsang/bottom?

We'll need some numbers in order to investigate this further

@LGUG2Z commented on GitHub (Jun 2, 2024): Can you try taking some measurements with a command line tool like https://github.com/ClementTsang/bottom? We'll need some numbers in order to investigate this further

adam commented

@KevinNitroG commented on GitHub (Jun 2, 2024):

Can you try taking some measurements with a command line tool like ClementTsang/bottom?

We'll need some numbers in order to investigate this further

Thank you for your reply. I will record another video with bottom later when the issue comes up.

@KevinNitroG commented on GitHub (Jun 2, 2024): > Can you try taking some measurements with a command line tool like [ClementTsang/bottom](https://github.com/ClementTsang/bottom)? > > We'll need some numbers in order to investigate this further Thank you for your reply. I will record another video with `bottom` later when the issue comes up.

adam commented

@KevinNitroG commented on GitHub (Jun 2, 2024):

@LGUG2Z Here is the video using bottom.

The fastest way to reproduce this is by switching workspaces continuously (about 100 times? - instead of using komorebi for a while).

@KevinNitroG commented on GitHub (Jun 2, 2024): @LGUG2Z Here is the video using `bottom`. ![Video with bottom](https://github.com/LGUG2Z/komorebi/assets/86353526/ea8b0e38-b24b-4e9d-aae4-eb4912291b1b) The fastest way to reproduce this is by switching workspaces continuously (about 100 times? - instead of using komorebi for a while).

adam commented

@KevinNitroG commented on GitHub (Jun 2, 2024):

I will use the older version 0.1.25 and check if the issue appears or not. Then I will let you know later.

Edit:

I uninstall using

scoop uninstall komorebi -p
scoop cleanup -a

Then install using

scoop install komorebi@0.1.25

the output

WARN  Given version (0.1.25) does not match manifest (0.1.26)
WARN  Attempting to generate manifest for 'komorebi' (0.1.25)
Autoupdating komorebi
Downloading komorebi-0.1.25-x86_64-pc-windows-msvc.zip to compute hashes!
Loading komorebi-0.1.25-x86_64-pc-windows-msvc.zip from cache
Computed hash: 8da0d8f4f5316ef2be2c6217296d3b57391ef5349761ec56e540697602435d91
Writing updated komorebi manifest
Installing 'komorebi' (0.1.25) [64bit] from 'C:\Users\kevinnitro\scoop\workspace\komorebi.json'
Loading komorebi-0.1.25-x86_64-pc-windows-msvc.zip from cache
Checking hash of komorebi-0.1.25-x86_64-pc-windows-msvc.zip ... ok.
Extracting komorebi-0.1.25-x86_64-pc-windows-msvc.zip ... done.
Linking ~\scoop\apps\komorebi\current => ~\scoop\apps\komorebi\0.1.25
Creating shim for 'komorebi'.
Creating shim for 'komorebic'.
Creating shim for 'komorebic-no-console'.
Making C:\Users\kevinnitro\scoop\shims\komorebic-no-console.exe a GUI binary.
Creating shim for 'komorebi-gui'.
Get-Command: C:\Users\kevinnitro\scoop\apps\scoop\current\lib\install.ps1:783
Line |
 783 |              $bin = (Get-Command $target).Source
     |                      ~~~~~~~~~~~~~~~~~~~
     | The term 'komorebi-gui.exe' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of
     | the name, or if a path was included, verify that the path is correct and try again.
Can't shim 'komorebi-gui.exe': File doesn't exist.

But komorebi still works

@KevinNitroG commented on GitHub (Jun 2, 2024): I will use the older version `0.1.25` and check if the issue appears or not. Then I will let you know later. Edit: I uninstall using ```ps1 scoop uninstall komorebi -p scoop cleanup -a ``` Then install using ```ps1 scoop install komorebi@0.1.25 ``` the output ```log WARN Given version (0.1.25) does not match manifest (0.1.26) WARN Attempting to generate manifest for 'komorebi' (0.1.25) Autoupdating komorebi Downloading komorebi-0.1.25-x86_64-pc-windows-msvc.zip to compute hashes! Loading komorebi-0.1.25-x86_64-pc-windows-msvc.zip from cache Computed hash: 8da0d8f4f5316ef2be2c6217296d3b57391ef5349761ec56e540697602435d91 Writing updated komorebi manifest Installing 'komorebi' (0.1.25) [64bit] from 'C:\Users\kevinnitro\scoop\workspace\komorebi.json' Loading komorebi-0.1.25-x86_64-pc-windows-msvc.zip from cache Checking hash of komorebi-0.1.25-x86_64-pc-windows-msvc.zip ... ok. Extracting komorebi-0.1.25-x86_64-pc-windows-msvc.zip ... done. Linking ~\scoop\apps\komorebi\current => ~\scoop\apps\komorebi\0.1.25 Creating shim for 'komorebi'. Creating shim for 'komorebic'. Creating shim for 'komorebic-no-console'. Making C:\Users\kevinnitro\scoop\shims\komorebic-no-console.exe a GUI binary. Creating shim for 'komorebi-gui'. Get-Command: C:\Users\kevinnitro\scoop\apps\scoop\current\lib\install.ps1:783 Line | 783 | $bin = (Get-Command $target).Source | ~~~~~~~~~~~~~~~~~~~ | The term 'komorebi-gui.exe' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of | the name, or if a path was included, verify that the path is correct and try again. Can't shim 'komorebi-gui.exe': File doesn't exist. ``` But komorebi still works

adam commented

@KevinNitroG commented on GitHub (Jun 2, 2024):

Update: I can confirm that the version 0.1.25 has no problem with high CPU and fan speed 😶‍🌫️

@KevinNitroG commented on GitHub (Jun 2, 2024): Update: I can confirm that the version `0.1.25` has no problem with high CPU and fan speed 😶‍🌫️

adam commented

@LGUG2Z commented on GitHub (Jun 2, 2024):

Looking at your first video where you isolate the komorebi process: the ~20% CPU usage you point to is the total CPU usage across all running processes; komorebi's CPU usage is still 0%.

Similarly for the video with btm komorebi's CPU usage seems to peak at 0.1%.

Generally we target <1% CPU usage for komorebi running in the background and it seems like your measurements are consistent with that.

However I did notice that you seem to be running in 32-bit mode, while you are running other applications such as OBS in 64-bit mode? When you are running previous versions of komorebi are you also making them run in 32-bit mode?

@LGUG2Z commented on GitHub (Jun 2, 2024): Looking at your first video where you isolate the komorebi process: the ~20% CPU usage you point to is the total CPU usage across all running processes; komorebi's CPU usage is still 0%. Similarly for the video with `btm` komorebi's CPU usage seems to peak at `0.1%`. Generally we target <1% CPU usage for komorebi running in the background and it seems like your measurements are consistent with that. However I did notice that you seem to be running in 32-bit mode, while you are running other applications such as OBS in 64-bit mode? When you are running previous versions of komorebi are you also making them run in 32-bit mode?

adam commented

@KevinNitroG commented on GitHub (Jun 2, 2024):

Looking at your first video where you isolate the komorebi process: the ~20% CPU usage you point to is the total CPU usage across all running processes; komorebi's CPU usage is still 0%.

Similarly for the video with btm komorebi's CPU usage seems to peak at 0.1%.

Generally we target <1% CPU usage for komorebi running in the background and it seems like your measurements are consistent with that.

However I did notice that you seem to be running in 32-bit mode, while you are running other applications such as OBS in 64-bit mode? When you are running previous versions of komorebi are you also making them run in 32-bit mode?

Currently, I'm back to 0.1.25 and all of the versions I use, they are all run at 32-bit mode sir.

Also I don't know how to run komorebi in 64-bit mode 😥

@KevinNitroG commented on GitHub (Jun 2, 2024): > Looking at your first video where you isolate the komorebi process: the ~20% CPU usage you point to is the total CPU usage across all running processes; komorebi's CPU usage is still 0%. > > Similarly for the video with `btm` komorebi's CPU usage seems to peak at `0.1%`. > > Generally we target <1% CPU usage for komorebi running in the background and it seems like your measurements are consistent with that. > > However I did notice that you seem to be running in 32-bit mode, while you are running other applications such as OBS in 64-bit mode? When you are running previous versions of komorebi are you also making them run in 32-bit mode? Currently, I'm back to `0.1.25` and all of the versions I use, they are all run at 32-bit mode sir. ![image](https://github.com/LGUG2Z/komorebi/assets/86353526/12905f89-11ef-4db0-a00a-77a0cff58765) Also I don't know how to run komorebi in 64-bit mode 😥

adam commented

@LGUG2Z commented on GitHub (Jun 2, 2024):

I wonder if that 32-bit binary is the shim from scoop? 🤔

Since none of the measurements suggest that komorebi is using any more CPU resources than normal, can you check the logs and see and share if there is anything interesting happening there, like threads crashing and restarting?

@LGUG2Z commented on GitHub (Jun 2, 2024): I wonder if that 32-bit binary is the shim from `scoop`? 🤔 Since none of the measurements suggest that komorebi is using any more CPU resources than normal, can you check the logs and see and share if there is anything interesting happening there, like threads crashing and restarting?

adam commented

@KevinNitroG commented on GitHub (Jun 2, 2024):

I wonder if that 32-bit binary is the shim from scoop? 🤔

Since none of the measurements suggest that komorebi is using any more CPU resources than normal, can you check the logs and see and share if there is anything interesting happening there, like threads crashing and restarting?

Recently I tried to back to 0.1.26 and try to check the log with komorebic log. I switch between workspaces and there is no warning, or error log (except high CPU every time checking the log lifetime in the terminal - around + [20, 30] % 😐). But I will try again later and let you know if there is any warning or error log.

@KevinNitroG commented on GitHub (Jun 2, 2024): > I wonder if that 32-bit binary is the shim from `scoop`? 🤔 > > Since none of the measurements suggest that komorebi is using any more CPU resources than normal, can you check the logs and see and share if there is anything interesting happening there, like threads crashing and restarting? Recently I tried to back to `0.1.26` and try to check the log with `komorebic log`. I switch between workspaces and there is no warning, or error log (except high CPU every time checking the log lifetime in the terminal - around + [`20`, `30`] % 😐). But I will try again later and let you know if there is any warning or error log.

adam commented

@KevinNitroG commented on GitHub (Jun 2, 2024):

After trying to get some logs in the 0.1.26 version, There were some logs that also occurred in 0.1.25 so I think we cannot find the problem via log 😥.

There was an error whenever I spawned a new window / app. For example Spotify (always at a specific workspace)
```
2024-06-02T16:52:13.127031Z ERROR komorebi::process_event: there is no container/window
```

Also when I resized a window, there were warnings that the window could not be resized, but in fact, it was resized normally.

2024-06-02T17:10:59.299093Z  WARN process_command{ResizeWindowAxis(Horizontal, Decrease)}:resize_window{direction=Left sizing=Decrease delta=20

After some try, it couldn't run komorebic log again and showed an error

Error: The system cannot find the file specified. (os error 2)

Location:
    komorebic\src\main.rs:1499:40

I did restart komorebi, but it couldn't show the log and threw the same error. Same with reinstalling komorebi. (note that 0.1.26)

Then I went back to 0.1.25 and it could show log normally.

Then I reinstalled 0.1.26, and it threw the same error when using komorebic log

@KevinNitroG commented on GitHub (Jun 2, 2024): After trying to get some logs in the `0.1.26` version, There were some logs that also occurred in `0.1.25` so I think we cannot find the problem via log 😥. 1. There was an error whenever I spawned a new window / app. For example Spotify (always at a specific workspace) ``` 2024-06-02T16:52:13.127031Z ERROR komorebi::process_event: there is no container/window ``` 2. Also when I resized a window, there were warnings that the window could not be resized, but in fact, it was resized normally. ``` 2024-06-02T17:10:59.299093Z WARN process_command{ResizeWindowAxis(Horizontal, Decrease)}:resize_window{direction=Left sizing=Decrease delta=20 ``` --- After some try, it couldn't run `komorebic log` again and showed an error ``` Error: The system cannot find the file specified. (os error 2) Location: komorebic\src\main.rs:1499:40 ``` I did restart komorebi, but it couldn't show the log and threw the same error. Same with reinstalling komorebi. (note that `0.1.26`) --- Then I went back to `0.1.25` and it could show log normally. --- Then I reinstalled `0.1.26`, and it threw the same error when using `komorebic log`

adam commented

@LGUG2Z commented on GitHub (Jun 2, 2024):

🤦‍♀️ I forgot there was a regression in the log command that was fixed here on master: 1320b7440e

Can you try running v0.1.27-dev.0 from the latest commit on the master branch?

@LGUG2Z commented on GitHub (Jun 2, 2024): 🤦‍♀️ I forgot there was a regression in the log command that was fixed here on master: https://github.com/LGUG2Z/komorebi/commit/1320b7440ee3b69a20c28ba415da6eb78d57ad9f Can you try running `v0.1.27-dev.0` from the latest commit on the `master` branch?

adam commented

@KevinNitroG commented on GitHub (Jun 2, 2024):

🤦‍♀️ I forgot there was a regression in the log command that was fixed here on master: 1320b74

Can you try running v0.1.27-dev.0 from the latest commit on the master branch?

So I need to build from source right? I have never built a rust project before 😂 Alright I will give it a try tomorrow. And grab if there is any valuable log.

Edit: Is that possible to run directly the .exe from the artifact of github action's workflow, I wonder?

@KevinNitroG commented on GitHub (Jun 2, 2024): > 🤦‍♀️ I forgot there was a regression in the log command that was fixed here on master: [1320b74](https://github.com/LGUG2Z/komorebi/commit/1320b7440ee3b69a20c28ba415da6eb78d57ad9f) > > Can you try running `v0.1.27-dev.0` from the latest commit on the `master` branch? So I need to build from source right? I have never built a rust project before 😂 Alright I will give it a try tomorrow. And grab if there is any valuable log. Edit: Is that possible to run directly the .exe from the artifact of github action's workflow, I wonder?

adam commented

@LGUG2Z commented on GitHub (Jun 2, 2024):

Yeah you can replace the exes on your system with the exes from GitHub actions ^

@LGUG2Z commented on GitHub (Jun 2, 2024): Yeah you can replace the exes on your system with the exes from GitHub actions ^

adam commented

@KevinNitroG commented on GitHub (Jun 3, 2024):

@LGUG2Z

The issue (High CPU) still exists in fix(cli): make quickstart respect whkd config dir #2003. And there wasn't any valuable log. 😥

@KevinNitroG commented on GitHub (Jun 3, 2024): @LGUG2Z The issue (High CPU) still exists in [fix(cli): make quickstart respect whkd config dir #2003](https://github.com/LGUG2Z/komorebi/commit/9a0ee8e8ddae434379e94d2d15a99918c479366e). And there wasn't any valuable log. 😥

adam commented

@thomasroodnl commented on GitHub (Jun 7, 2024):

Dear @KevinNitroG , @LGUG2Z

I seem to be having a similar issue since v0.1.26. In Task Manager komorebi.exe CPU usage is reported in the 25%-50% range on idle, and by bottom in the 8-12% range. If I relaunch komorebi it goes back to <1% (on both). I can reproduce it by launching komorebi (which now has all of my windows (~8) in the first workspace) and quickly switching between it and the empty second workspace. Doing this about 20-30 times already gets me in the 4-8% idle CPU usage on bottom.

I tried it with less windows (4) and closed some nefarious applications like PyCharm, and I can still reproduce the increased idle CPU.

I think that during my normal workflow this problem gradually increases the idle CPU usage until all my applications start hanging due to how busy the CPU is. Another thing I note is that my active_window_borders disappear after some time, which may or may not be related to this issue.

My setup is as follows:

komorebi.json:

{
  "$schema": "https://raw.githubusercontent.com/LGUG2Z/komorebi/v0.1.26/schema.json",
  "app_specific_configuration_path": "C:/Users/trood/Repos/komorebi-config/applications.yaml",
  "window_hiding_behaviour": "Cloak",
  "cross_monitor_move_behaviour": "Insert",
  "float_rules": [], // REDACTED
  "unmanaged_window_operation_behaviour": "Op",
  "default_workspace_padding": 1,
  "default_container_padding": 1,
  "border_padding": 0,
  "border_offset": 0,
  "active_window_border": true,
  "border_width": 3,
  "global_work_area_offset": {"bottom":  -40, "left": 0, "right":  0, "top":  0},
  "active_window_border_colours": {
    "single": "#7582f8",
    "stack": "#7582f8",
    "monocle": "#9a45fa"
  },
  "monitors": [
    {
      "workspaces": [
        { "name": "0_I", "layout": "VerticalStack" },
        { "name": "0_II", "layout": "VerticalStack" },
        { "name": "0_III", "layout": "VerticalStack" },
        { "name": "0_IV", "layout": "VerticalStack" },
        { "name": "0_V", "layout": "VerticalStack" }
      ]
    },
    {
      "workspaces": [
        { "name": "1_I", "layout": "VerticalStack" },
        { "name": "1_II", "layout": "VerticalStack" },
        { "name": "1_III", "layout": "VerticalStack" },
        { "name": "1_IV", "layout": "VerticalStack" },
        { "name": "1_V", "layout": "VerticalStack" }
      ]
    },
    {
      "workspaces": [
        { "name": "2_I", "layout": "Rows" },
        { "name": "2_II", "layout": "Rows" },
        { "name": "2_III", "layout": "Rows" },
        { "name": "2_IV", "layout": "Rows" },
        { "name": "2_V", "layout": "Rows" }
      ]
    }
  ]
}

OS:

Edition	Windows 10 Pro
Version	22H2
Installed on	‎06/‎12/‎2022
OS build	19045.4412
Experience	Windows Feature Experience Pack 1000.19056.1000.0

It is maybe also good to note that I use yasb, and AutoHotkey v1 for my keybinds.

If there is anything that I could test to help track down the problem, please let me know.

@thomasroodnl commented on GitHub (Jun 7, 2024): Dear @KevinNitroG , @LGUG2Z I seem to be having a similar issue since v0.1.26. In Task Manager komorebi.exe CPU usage is reported in the 25%-50% range on idle, and by `bottom` in the 8-12% range. If I relaunch komorebi it goes back to <1% (on both). I can reproduce it by launching komorebi (which now has all of my windows (~8) in the first workspace) and quickly switching between it and the empty second workspace. Doing this about 20-30 times already gets me in the 4-8% idle CPU usage on `bottom`. I tried it with less windows (4) and closed some nefarious applications like PyCharm, and I can still reproduce the increased idle CPU. I think that during my normal workflow this problem gradually increases the idle CPU usage until all my applications start hanging due to how busy the CPU is. Another thing I note is that my `active_window_border`s disappear after some time, which may or may not be related to this issue. My setup is as follows: **komorebi.json**: ```json { "$schema": "https://raw.githubusercontent.com/LGUG2Z/komorebi/v0.1.26/schema.json", "app_specific_configuration_path": "C:/Users/trood/Repos/komorebi-config/applications.yaml", "window_hiding_behaviour": "Cloak", "cross_monitor_move_behaviour": "Insert", "float_rules": [], // REDACTED "unmanaged_window_operation_behaviour": "Op", "default_workspace_padding": 1, "default_container_padding": 1, "border_padding": 0, "border_offset": 0, "active_window_border": true, "border_width": 3, "global_work_area_offset": {"bottom": -40, "left": 0, "right": 0, "top": 0}, "active_window_border_colours": { "single": "#7582f8", "stack": "#7582f8", "monocle": "#9a45fa" }, "monitors": [ { "workspaces": [ { "name": "0_I", "layout": "VerticalStack" }, { "name": "0_II", "layout": "VerticalStack" }, { "name": "0_III", "layout": "VerticalStack" }, { "name": "0_IV", "layout": "VerticalStack" }, { "name": "0_V", "layout": "VerticalStack" } ] }, { "workspaces": [ { "name": "1_I", "layout": "VerticalStack" }, { "name": "1_II", "layout": "VerticalStack" }, { "name": "1_III", "layout": "VerticalStack" }, { "name": "1_IV", "layout": "VerticalStack" }, { "name": "1_V", "layout": "VerticalStack" } ] }, { "workspaces": [ { "name": "2_I", "layout": "Rows" }, { "name": "2_II", "layout": "Rows" }, { "name": "2_III", "layout": "Rows" }, { "name": "2_IV", "layout": "Rows" }, { "name": "2_V", "layout": "Rows" } ] } ] } ``` **OS**: ``` Edition Windows 10 Pro Version 22H2 Installed on ‎06/‎12/‎2022 OS build 19045.4412 Experience Windows Feature Experience Pack 1000.19056.1000.0 ``` It is maybe also good to note that I use `yasb`, and AutoHotkey v1 for my keybinds. If there is anything that I could test to help track down the problem, please let me know.

adam commented

3232d9242a
6c90001c00

@LGUG2Z commented on GitHub (Jun 7, 2024):

Another thing I note is that my active_window_borders disappear after some time, which may or may not be related to this issue.

This one at least I believe should be fixed on master:

I'm still not able to reproduce this on my end, but I will keep trying - It's possible there are some lock contention issues that only trigger under very specific conditions

@LGUG2Z commented on GitHub (Jun 7, 2024): > Another thing I note is that my active_window_borders disappear after some time, which may or may not be related to this issue. This one at least I believe should be fixed on master: https://github.com/LGUG2Z/komorebi/commit/3232d9242adbbc7ab59ddf428dbf8258313e7a31 https://github.com/LGUG2Z/komorebi/commit/6c90001c002ca643afd8d3ecb93db2915e3533f5 I'm still not able to reproduce this on my end, but I will keep trying - It's possible there are some lock contention issues that only trigger under very specific conditions

adam commented

@thomasroodnl commented on GitHub (Jun 7, 2024):

Ah that is good to hear, I will try building the current master! In the meantime, I tried reproducing it without yasb and I get the same issue so at least it is not that.

@thomasroodnl commented on GitHub (Jun 7, 2024): Ah that is good to hear, I will try building the current master! In the meantime, I tried reproducing it without `yasb` and I get the same issue so at least it is not that.

adam commented

@starise commented on GitHub (Jun 8, 2024):

I have the same issue described by @thomasroodnl : I'm working, time passes (hours) and the CPU usage increases until at some point I'm forced to exit komorebi to stop the system being slow. After komorebic stop all back to normal. In my workflow I also change workspaces several times during the day, moving windows around between workspaces.

@starise commented on GitHub (Jun 8, 2024): I have the same issue described by @thomasroodnl : I'm working, time passes (hours) and the CPU usage increases until at some point I'm forced to exit komorebi to stop the system being slow. After `komorebic stop` all back to normal. In my workflow I also change workspaces several times during the day, moving windows around between workspaces.

adam commented

@LGUG2Z commented on GitHub (Jun 8, 2024):

Is anyone able to reproduce this with borders off?

My working theory is that this comes down to the locks on Mutexes when handling WM_PAINT on border windows, and this becomes more and more noticable depending on the number of windows on each workspace that the user switches between.

@LGUG2Z commented on GitHub (Jun 8, 2024): Is anyone able to reproduce this with borders off? My working theory is that this comes down to the locks on Mutexes when handling `WM_PAINT` on border windows, and this becomes more and more noticable depending on the number of windows on each workspace that the user switches between.

adam commented

@starise commented on GitHub (Jun 8, 2024):

Is anyone able to reproduce this with borders off?

Changed my config to "border": false. I'll let you know.

@starise commented on GitHub (Jun 8, 2024): > Is anyone able to reproduce this with borders off? Changed my config to `"border": false`. I'll let you know.

adam commented

493531e764
0940fce05a

@LGUG2Z commented on GitHub (Jun 9, 2024):

I've been making some small performance refactors in the border manager's hot path here:

@LGUG2Z commented on GitHub (Jun 9, 2024): I've been making some small performance refactors in the border manager's hot path here: https://github.com/LGUG2Z/komorebi/commit/493531e764604a51cc8912c43239931855fbe453 https://github.com/LGUG2Z/komorebi/commit/0940fce05aa0f6b0ca4b885da6b87dac6eb1de4c

adam commented

@LGUG2Z commented on GitHub (Jun 9, 2024):

6b9a0843fd

This should also change the rate at which we trigger the border manager's hot path.

@LGUG2Z commented on GitHub (Jun 9, 2024): https://github.com/LGUG2Z/komorebi/commit/6b9a0843fd2eb186d53369ee6d8d47ec4c95fd59 This should also change the rate at which we trigger the border manager's hot path.

adam commented

@thomasroodnl commented on GitHub (Jun 10, 2024):

Is anyone able to reproduce this with borders off?

My working theory is that this comes down to the locks on Mutexes when handling WM_PAINT on border windows, and this becomes more and more noticable depending on the number of windows on each workspace that the user switches between.

I just tried to replicate it with the borders off and it seems like the issue indeed does not appear. CPU usage stays <1% (in bottom) both wile switching workspaces and afterwards. I will now build the latest from master and see what the performance is like with the borders enabled.

@thomasroodnl commented on GitHub (Jun 10, 2024): > Is anyone able to reproduce this with borders off? > > My working theory is that this comes down to the locks on Mutexes when handling `WM_PAINT` on border windows, and this becomes more and more noticable depending on the number of windows on each workspace that the user switches between. I just tried to replicate it with the borders off and it seems like the issue indeed does not appear. CPU usage stays <1% (in `bottom`) both wile switching workspaces and afterwards. I will now build the latest from master and see what the performance is like with the borders enabled.

adam commented

@starise commented on GitHub (Jun 11, 2024):

Same here. Monitored for an entire day with borders disabled and no issues so far.

@starise commented on GitHub (Jun 11, 2024): Same here. Monitored for an entire day with borders disabled and no issues so far.

adam commented

@LGUG2Z commented on GitHub (Jun 11, 2024):

Any updates to report with the latest changes on the master branch? 🤞

@LGUG2Z commented on GitHub (Jun 11, 2024): Any updates to report with the latest changes on the master branch? 🤞

adam commented

@thomasroodnl commented on GitHub (Jun 11, 2024):

Apologies, I have been running without borders enabled since this was working well so I forgot to check. I recompiled from master just now. With borders enabled I can still elicit the high idle CPU usage with the method as described before.

@thomasroodnl commented on GitHub (Jun 11, 2024): Apologies, I have been running without borders enabled since this was working well so I forgot to check. I recompiled from master just now. With borders enabled I can still elicit the high idle CPU usage with the method as described before.

adam commented

@LGUG2Z commented on GitHub (Jun 11, 2024):

Some elevated CPU usage is expected for expensive operations like this, especially when spamming workspace changes quickly over a few seconds to force a repro - but does the CPU usage continue to climb and stay high during normal usage and when idling on a single workspace?

@LGUG2Z commented on GitHub (Jun 11, 2024): Some elevated CPU usage is expected for expensive operations like this, especially when spamming workspace changes quickly over a few seconds to force a repro - but does the CPU usage continue to climb and stay high during normal usage and when idling on a single workspace?

adam commented

@thomasroodnl commented on GitHub (Jun 11, 2024):

Yes that makes sense. In this 'aggressive' reproduction it stays high when idling on a workspace for at least around 5 mins, I have not tested it for a longer period of time as I had to go back to using my pc. To validate further, I will enable the borders during normal usage and keep an eye on the CPU in idle.

@thomasroodnl commented on GitHub (Jun 11, 2024): Yes that makes sense. In this 'aggressive' reproduction it stays high when idling on a workspace for at least around 5 mins, I have not tested it for a longer period of time as I had to go back to using my pc. To validate further, I will enable the borders during normal usage and keep an eye on the CPU in idle.

adam commented

@starise commented on GitHub (Jun 11, 2024):

I'm testing this artifact today with borders on, and after a couple hours the system started to be sluggish with komorebi cpu usage from ~6-8% (in idle) to ~13-14% (peaks).

Tried a couple of komorebic border disable; komorebic border enable from PS but actually CPU usage increased a bit in idle. Only way to free resource is to start fresh with komorebic stop; komorebic start.

@starise commented on GitHub (Jun 11, 2024): I'm testing [this artifact](https://github.com/LGUG2Z/komorebi/actions/runs/9456043281) today with borders on, and after a couple hours the system started to be sluggish with komorebi cpu usage from ~6-8% (in idle) to ~13-14% (peaks). Tried a couple of `komorebic border disable; komorebic border enable` from PS but actually CPU usage increased a bit in idle. Only way to free resource is to start fresh with `komorebic stop; komorebic start`. ![komorebi cpu usage](https://github.com/LGUG2Z/komorebi/assets/2684482/d056e5d7-1bd2-4de0-9edb-8d13c9657a70)

adam commented

https://learn.microsoft.com/en-us/visualstudio/debugger/attach-to-running-processes-with-the-visual-studio-debugger?view=vs-2022

@LGUG2Z commented on GitHub (Jun 12, 2024):

I think I'm gonna have to try this out on a potato laptop 🤔

Can you share your hardware stats? For ref, I am testing this on a Ryzen 5900x

Similarly, it would be useful if anyone still experiencing high CPU usage could use Visual Studio to attach to the process and profile the CPU usage for a couple of minutes (hit "break all" after letting it run) to identify the hot code paths as it runs on your machines:

@LGUG2Z commented on GitHub (Jun 12, 2024): I think I'm gonna have to try this out on a potato laptop 🤔 Can you share your hardware stats? For ref, I am testing this on a Ryzen 5900x Similarly, it would be useful if anyone still experiencing high CPU usage could use Visual Studio to attach to the process and profile the CPU usage for a couple of minutes (hit "break all" after letting it run) to identify the hot code paths as it runs on your machines: https://learn.microsoft.com/en-us/visualstudio/debugger/attach-to-running-processes-with-the-visual-studio-debugger?view=vs-2022

adam commented

@starise commented on GitHub (Jun 12, 2024):

Can you share your hardware stats? For ref, I am testing this on a Ryzen 5900x

Sure, same CPU here 😅 - OS : Windows 11 (10.0.26100.712) - CPU : Ryzen 5900X - RAM : 64 GB - VGA: Radeon RX 6800 XT - Display (single) @ 2160p, 120Hz, 200% scaling. I'm using komorebi with 4 workspaces and these are my common apps: explorer, terminal, firefox, vscode, xnview mp, figma, davinci resolve.

@starise commented on GitHub (Jun 12, 2024): > Can you share your hardware stats? For ref, I am testing this on a Ryzen 5900x Sure, same CPU here 😅 - OS : Windows 11 (10.0.26100.712) - CPU : Ryzen 5900X - RAM : 64 GB - VGA: Radeon RX 6800 XT - Display (single) @ 2160p, 120Hz, 200% scaling. I'm using komorebi with 4 workspaces and these are my common apps: explorer, terminal, firefox, vscode, xnview mp, figma, davinci resolve.

adam commented

@thomasroodnl commented on GitHub (Jun 12, 2024):

Today I used komorebi with the borders enabled without any violent workspace shifting. After around 4 hours the CPU usage was noticeably high in idle (4-8%), even after not doing any window switches for several minutes. I performed the profiling like you requested and got the following summary:

During this recording I did not interact with the machine. Please let me know if you need a different view of this trace or need me to send you the trace file (I'd need to figure out how first).

Oh and also, the 'potato laptop' hit home :). I am running a 12th Gen Intel(R) Core(TM) i7-1255U, and 16 GB of RAM. No dedicated graphics card. Current test was with single display @ 1440p, 100Hz, 100% scaling. 5 workspaces.

@thomasroodnl commented on GitHub (Jun 12, 2024): Today I used komorebi with the borders enabled without any violent workspace shifting. After around 4 hours the CPU usage was noticeably high in idle (4-8%), even after not doing any window switches for several minutes. I performed the profiling like you requested and got the following summary: ![image](https://github.com/LGUG2Z/komorebi/assets/67050654/5cf095f5-aede-4a9e-a72a-954309078456) During this recording I did not interact with the machine. Please let me know if you need a different view of this trace or need me to send you the trace file (I'd need to figure out how first). Oh and also, the 'potato laptop' hit home :). I am running a 12th Gen Intel(R) Core(TM) i7-1255U, and 16 GB of RAM. No dedicated graphics card. Current test was with single display @ 1440p, 100Hz, 100% scaling. 5 workspaces.

adam commented

https://github.com/LGUG2Z/komorebi/assets/165908630/a790c1ef-b933-4277-bd2a-7ea450492325

@CtByte commented on GitHub (Jun 12, 2024):

I've been using Komorebi for 7 hours now with borders and transparency enabled. I have many windows open (6 terminals, 2 Visual Studio 2022, Teams, Chrome, Firefox, etc)

I did a little test where I grabbed a window an observed the CPU usage:

I only observed considerable CPU usage while I was holding the window. It went back to 0%

I am using the 67a3c3546f version which I built myself using Visual Studio 2022. I copied the exe files to the c:\Program Files\komorebi\bin\ folder. I don't really think that it has anything to do with the files you are testing with, but I thought I mention it.

I use stackbar a lot and having transparency+borders does not seem to be an issue for me.

Could this have more to do with workspaces? or perhaps the fact that you don't have dedicated GPU to render the borders and other graphical intense workloads so Windows reserves a bit of the CPU for when it needs to use the integrated GPU (it does that with RAM)?

OS Name:                   Microsoft Windows 11 Pro
OS Version:                10.0.22631 N/A Build 22631
CPU:                       12th Gen Intel(R) Core(TM) i9-12900H
GPU:                       NVIDIA GeForce RTX 3070 Ti Laptop GPU
RAM:                       48 GB

Edit: After reading a bit more above, I can see that others with a dedicated GPU have similar issues. This one is difficult to crack.

@CtByte commented on GitHub (Jun 12, 2024): I've been using Komorebi for 7 hours now with borders and transparency enabled. I have many windows open (6 terminals, 2 Visual Studio 2022, Teams, Chrome, Firefox, etc) I did a little test where I grabbed a window an observed the CPU usage: https://github.com/LGUG2Z/komorebi/assets/165908630/a790c1ef-b933-4277-bd2a-7ea450492325 I only observed considerable CPU usage while I was holding the window. It went back to 0% I am using the 67a3c3546f5c192285e0dd3458ce818462ce53e5 version which I built myself using Visual Studio 2022. I copied the exe files to the `c:\Program Files\komorebi\bin\` folder. I don't really think that it has anything to do with the files you are testing with, but I thought I mention it. I use stackbar a lot and having transparency+borders does not seem to be an issue for me. Could this have more to do with workspaces? or perhaps the fact that you don't have dedicated GPU to render the borders and other graphical intense workloads so Windows reserves a bit of the CPU for when it needs to use the integrated GPU (it does that with RAM)? ``` OS Name: Microsoft Windows 11 Pro OS Version: 10.0.22631 N/A Build 22631 CPU: 12th Gen Intel(R) Core(TM) i9-12900H GPU: NVIDIA GeForce RTX 3070 Ti Laptop GPU RAM: 48 GB ``` Edit: After reading a bit more above, I can see that others with a dedicated GPU have similar issues. This one is difficult to crack.

adam commented

67a3c3546f/komorebi/src/border_manager/border.rs (L123-L137)

@LGUG2Z commented on GitHub (Jun 12, 2024):

Since this issue is getting quite long, here is a quick summary of what the investigation so far has shown:

The core issue is not that drawing borders and changing workspaces consumes CPU cycles, but that komorebi.exe continues to consume CPU cycles at a growing rate over the lifetime of the process
There is no clear reproduction for this core issue - this only presents on the machines of some users, but not all users
The exact combination of conditions required for the core issue to present for the impacted subset of users remains unknown
- One of the conditions for the core issue to present for the impacted subset of users is enabling borders
- The core issue has not presented for people using dedicated Nvidia graphics cards
- The core issue has presented on both Intel and AMD CPUs
Although there have been significant performance improvements after code changes shared earlier in this thread in the extreme case of rapidly switching workspaces (on my machine, v0.1.26 has this going up to 4-5% CPU usage, and master has it always under 1.5% CPU usage), these changes have not addressed the core issue

A few things that come to mind for the next steps:

Since the core issue only presents when borders are enabled, we should continue looking in the border_manager module
Since we have already aggressively optimized our own logic in border_manager, the underlying issue is probably somewhere in the Win32 system calls we are making
The Win32 system calls in the border manager are in the update and callback functions
- update triggers InvalidateRect which triggers the WM_PAINT message being sent to each border window

67a3c3546f/komorebi/src/border_manager/border.rs (L152-L211)

Although this is not documented in the WM_PAINT docs, there is an old StackOverflow comment which states:

This is entirely normal. Windows generates the WM_PAINT message when your window's update region in not empty. What you are supposed to do is mark it empty again. You do so, for example, by calling Begin/EndPaint().

If you don't then Windows immediately generates yet another WM_PAINT message, still trying to get the update region emptied. Your thread will burn 100% core, idly processing WM_PAINT messages and not actually getting the job done. Maybe you are actually painting, Windows just doesn't know what you painted and doesn't try to guess at it.

Using Begin/EndPaint() is very much the sane way to get that job done. It isn't the only way, you could also call ValidateRect() or ValidateRgn(). As long as you are "new to winapi", I'd very strongly recommend you do this the normal way.

Since we are calling if let Ok(rect) = WindowsApi::window_rect(window) {} as the very first step in the WM_PAINT handler, it's possible that this call could fail, triggering the WM_PAINT message loops for a small subset of borders. We don't have any logging here to validate whether or not this is the case, but it should be possible to add both error logging and to push the BeginPaint and EndPaint calls outside of the rect context.

All of the Win32 system calls here are GDI-related, so if you are a game dev using komorebi and you're reading this, please double check all of my assumptions. 😅

Edit: The changes to the WM_PAINT handler have been made on master, and I've also added another change which only triggers the WM_PAINT message if either the focus state or the rect position has changed.

@LGUG2Z commented on GitHub (Jun 12, 2024): Since this issue is getting quite long, here is a quick summary of what the investigation so far has shown: * The **core issue** is not that drawing borders and changing workspaces consumes CPU cycles, but that `komorebi.exe` continues to consume CPU cycles at a growing rate over the lifetime of the process * There is no clear reproduction for this core issue - this only presents on the machines of **some users**, but not all users * The exact combination of conditions required for the core issue to present for the impacted subset of users remains unknown * **One of the conditions** for the core issue to present for the impacted subset of users is enabling borders * The core issue has not presented for people using dedicated Nvidia graphics cards * The core issue has presented on both Intel and AMD CPUs * Although there have been significant performance improvements after code changes shared earlier in this thread in the extreme case of rapidly switching workspaces (on my machine, v0.1.26 has this going up to 4-5% CPU usage, and master has it always under 1.5% CPU usage), these changes have not addressed the **core issue** A few things that come to mind for the next steps: * Since the core issue only presents when borders are enabled, we should continue looking in the `border_manager` module * Since we have already aggressively optimized our own logic in `border_manager`, the underlying issue is probably somewhere in the Win32 system calls we are making * The Win32 system calls in the border manager are in the `update` and `callback` functions * `update` triggers `InvalidateRect` which triggers the `WM_PAINT` message being sent to each border window https://github.com/LGUG2Z/komorebi/blob/67a3c3546f5c192285e0dd3458ce818462ce53e5/komorebi/src/border_manager/border.rs#L123-L137 https://github.com/LGUG2Z/komorebi/blob/67a3c3546f5c192285e0dd3458ce818462ce53e5/komorebi/src/border_manager/border.rs#L152-L211 Although this is not documented in the [`WM_PAINT` docs](https://learn.microsoft.com/en-us/windows/win32/gdi/wm-paint), there is an [old StackOverflow comment](https://stackoverflow.com/a/21354578) which states: > This is entirely normal. Windows generates the WM_PAINT message when your window's update region in not empty. What you are supposed to do is mark it empty again. You do so, for example, by calling Begin/EndPaint(). > > If you don't then Windows immediately generates yet another WM_PAINT message, still trying to get the update region emptied. Your thread will burn 100% core, idly processing WM_PAINT messages and not actually getting the job done. Maybe you are actually painting, Windows just doesn't know what you painted and doesn't try to guess at it. > > Using Begin/EndPaint() is very much the sane way to get that job done. It isn't the only way, you could also call ValidateRect() or ValidateRgn(). As long as you are "new to winapi", I'd very strongly recommend you do this the normal way. Since we are calling `if let Ok(rect) = WindowsApi::window_rect(window) {}` as the very first step in the `WM_PAINT` handler, it's possible that this call could fail, triggering the `WM_PAINT` message loops for a small subset of borders. We don't have any logging here to validate whether or not this is the case, but it should be possible to add both error logging and to push the `BeginPaint` and `EndPaint` calls outside of the `rect` context. All of the Win32 system calls here are GDI-related, so if you are a game dev using `komorebi` and you're reading this, please double check all of my assumptions. 😅 Edit: The changes to the `WM_PAINT` handler have been made on `master`, and I've also added another change which only triggers the `WM_PAINT` message if either the focus state or the rect position has changed.

adam commented

@LGUG2Z commented on GitHub (Jun 14, 2024):

Has anyone been able to run with the latest changes? 🤞

@LGUG2Z commented on GitHub (Jun 14, 2024): Has anyone been able to run with the latest changes? 🤞

adam commented

@starise commented on GitHub (Jun 14, 2024):

I'm testing c022438a37 right now and the situation looks much better. Changing workspace frequently caused some cpu spikes but nothing dramatic. On idle cpu usage seems under control. I also noticed less memory utilization overall. I'll monitor the situation under a more extensive period of time. I'll keep you updated. 👌

@starise commented on GitHub (Jun 14, 2024): I'm testing https://github.com/LGUG2Z/komorebi/commit/c022438a37c811d5aa188386987bea4a88bc2833 right now and the situation looks much better. Changing workspace frequently caused some cpu spikes but nothing dramatic. On idle cpu usage seems under control. I also noticed less memory utilization overall. I'll monitor the situation under a more extensive period of time. I'll keep you updated. 👌

adam commented

@Q0 commented on GitHub (Jun 15, 2024):

I’m sitting on c022438 and in general everything is very stable. I have never had a window border break (previously it often broke when actively working with windows). The review is positive.

@Q0 commented on GitHub (Jun 15, 2024): I’m sitting on c022438 and in general everything is very stable. I have never had a window border break (previously it often broke when actively working with windows). The review is positive.

adam commented

@LGUG2Z commented on GitHub (Jun 15, 2024):

@thomasroodnl @KevinNitroG if either if you can also confirm the improvements on your end we should be able to close this and begin the next release cycle 🤞

@LGUG2Z commented on GitHub (Jun 15, 2024): @thomasroodnl @KevinNitroG if either if you can also confirm the improvements on your end we should be able to close this and begin the next release cycle 🤞

adam commented

@thomasroodnl commented on GitHub (Jun 15, 2024):

Great to hear the changes seem to be having the desired effect :). I'm sorry, I haven't had the opportunity yet to build the latest version and run it, but I will give it a try coming Monday and report my findings.

@thomasroodnl commented on GitHub (Jun 15, 2024): Great to hear the changes seem to be having the desired effect :). I'm sorry, I haven't had the opportunity yet to build the latest version and run it, but I will give it a try coming Monday and report my findings.

adam commented

@KevinNitroG commented on GitHub (Jun 16, 2024):

@LGUG2Z Hi again. I think the commit c022438a37 is fine now. I haven't had enough long time to test but within an hour, my CPU's fan doesn't complain about komorebi anymore.

Also, this is not related to this issue. If I use komorebic close while on the desktop, it will close the windows explorer which makes the icon disappear. Is it ... a feature? 😶‍🌫️

Thank you for having looked into the bug. Love your project!

EDIT: BUT WAIT... 😅
Please let us test a bit more. I just want to ensure whether the issue is gone completely or not.

Edit: Not yet fine...

@KevinNitroG commented on GitHub (Jun 16, 2024): @LGUG2Z Hi again. I think the commit https://github.com/LGUG2Z/komorebi/commit/c022438a37c811d5aa188386987bea4a88bc2833 is fine now. I haven't had enough long time to test but within an hour, my CPU's fan doesn't complain about komorebi anymore. Also, this is not related to this issue. If I use `komorebic close` while on the desktop, it will close the windows explorer which makes the icon disappear. Is it ... a feature? 😶‍🌫️ Thank you for having looked into the bug. Love your project! EDIT: BUT WAIT... 😅 Please let us test a bit more. I just want to ensure whether the issue is gone completely or not. Edit: Not yet fine...

adam commented

https://github.com/LGUG2Z/komorebi/assets/86353526/a3e19acf-9c9a-4ed7-9b6d-61ac09638549

@KevinNitroG commented on GitHub (Jun 17, 2024):

@LGUG2Z. I'm testing c022438a37 for more than an hour and it seems that the issue hasn't gone completely yet I guess. My fan still goes up, but the CPU doesn't show that much, and I can only show you via the CPU temp.

After restarting komorebi, my fan goes down.

I will test it again and feedback to you later. But I think I will leave this issue soon because of personal busy. 😅

@KevinNitroG commented on GitHub (Jun 17, 2024): @LGUG2Z. I'm testing https://github.com/LGUG2Z/komorebi/commit/c022438a37c811d5aa188386987bea4a88bc2833 for more than an hour and it seems that the issue hasn't gone completely yet I guess. My fan still goes up, but the CPU doesn't show that much, and I can only show you via the CPU temp. https://github.com/LGUG2Z/komorebi/assets/86353526/a3e19acf-9c9a-4ed7-9b6d-61ac09638549 After restarting komorebi, my fan goes down. --- I will test it again and feedback to you later. But I think I will leave this issue soon because of personal busy. 😅

adam commented

https://github.com/LGUG2Z/komorebi/assets/86353526/2a6c1906-d297-4a42-a9c8-d415de459617

@KevinNitroG commented on GitHub (Jun 17, 2024):

Here is another video shows that my CPU temp is high, and decrease after restarting komorebi

@KevinNitroG commented on GitHub (Jun 17, 2024): https://github.com/LGUG2Z/komorebi/assets/86353526/2a6c1906-d297-4a42-a9c8-d415de459617 Here is another video shows that my CPU temp is high, and decrease after restarting komorebi

adam commented

@thomasroodnl commented on GitHub (Jun 17, 2024):

From a quick look the CPU performance seems largely improved. I can still repro the high idle CPU usage with the fast workspace switching, but I will just run it normally throughout the day and see how the idle looks for me under a more realistic workload. In any case, thanks for the improvements!

@thomasroodnl commented on GitHub (Jun 17, 2024): From a quick look the CPU performance seems largely improved. I can still repro the high idle CPU usage with the fast workspace switching, but I will just run it normally throughout the day and see how the idle looks for me under a more realistic workload. In any case, thanks for the improvements!

adam commented

@thomasroodnl commented on GitHub (Jun 17, 2024):

Just ran it for 4 hours on normal use. Idle komorebi CPU usage hovers around 1-4%. For me this is fine honestly, I haven't noticed any freezing or slowdown due to the extra CPU usage. But it seems there is still something going on in the background. I wanted to note that in general, the stability of the boundaries has improved significantly for me over the past updates.

@thomasroodnl commented on GitHub (Jun 17, 2024): Just ran it for 4 hours on normal use. Idle komorebi CPU usage hovers around 1-4%. For me this is fine honestly, I haven't noticed any freezing or slowdown due to the extra CPU usage. But it seems there is still something going on in the background. I wanted to note that in general, the stability of the boundaries has improved significantly for me over the past updates.

adam commented

@LGUG2Z commented on GitHub (Jun 18, 2024):

I'm going to close out this issue now; the core issue that we were able to measure through komorebi's CPU usage growing over time has been resolved, and I don't think we can take any investigation into hardware temperatures further right now since our main metrics (CPU usage) have completely normalized.

@LGUG2Z commented on GitHub (Jun 18, 2024): I'm going to close out this issue now; the core issue that we were able to measure through komorebi's CPU usage growing over time has been resolved, and I don't think we can take any investigation into hardware temperatures further right now since our main metrics (CPU usage) have completely normalized.

adam commented

@starise commented on GitHub (Jun 18, 2024):

Sadly I have to report that komorebi cpu usage gone wild again for me right now (Screenshot). 😢 I noticed that every time I switch the workspace, back and forth, it triggers new "Create Thread" events and never exit the threads.

@starise commented on GitHub (Jun 18, 2024): Sadly I have to report that komorebi cpu usage gone wild again for me right now ([Screenshot](https://i.imgur.com/Ko3cyLZ.png)). 😢 I noticed that every time I switch the workspace, back and forth, it triggers new "Create Thread" events and never exit the threads.

adam commented

@LGUG2Z commented on GitHub (Jun 18, 2024):

Do you have any errors in the logs which show threads crashing and bring restarted when you are changing workspaces? 🤔

@LGUG2Z commented on GitHub (Jun 18, 2024): Do you have any errors in the logs which show threads crashing and bring restarted when you are changing workspaces? 🤔

adam commented

@starise commented on GitHub (Jun 18, 2024):

You mean komorebic log? I uploaded a small video to show what I mean, I was watching "SimpleProgramDebugger" output and it looks like new threads are created every time I change a workspace, but I'm doing nothing except switching between the same 2 workspaces. The threads remain active and are closed on komorebic stop.

Uploaded a video here (Sry: GitHub has 10MB limit): https://streamable.com/p2x31u

@starise commented on GitHub (Jun 18, 2024): You mean `komorebic log`? I uploaded a small video to show what I mean, I was watching "[SimpleProgramDebugger](https://www.nirsoft.net/utils/simple_program_debugger.html)" output and it looks like new threads are created every time I change a workspace, but I'm doing nothing except switching between the same 2 workspaces. The threads remain active and are closed on `komorebic stop`. Uploaded a video here (Sry: GitHub has 10MB limit): https://streamable.com/p2x31u

adam commented

@LGUG2Z commented on GitHub (Jun 18, 2024):

These calls to CreateThread aren't being made from komorebi directly to the best of my knowledge, but it may be something in a library that we are calling. Another thing to make sure of is whether we see the same debugger output even when there is no elevated CPU usage 🤔

@LGUG2Z commented on GitHub (Jun 18, 2024): These calls to CreateThread aren't being made from `komorebi` directly to the best of my knowledge, but it may be something in a library that we are calling. Another thing to make sure of is whether we see the same debugger output even when there is no elevated CPU usage 🤔

adam commented

@starise commented on GitHub (Jun 18, 2024):

make sure of is whether we see the same debugger output even when there is no elevated CPU usage 🤔

If you take a closer look at my video, the cpu usage of komorebi.exe is very low (launched just in that moment). What has high cpu usage is komorebic.exe (after komorebic log command).

@starise commented on GitHub (Jun 18, 2024): > make sure of is whether we see the same debugger output even when there is no elevated CPU usage 🤔 If you take a closer look at my video, the cpu usage of `komorebi.exe` is very low (launched just in that moment). What has high cpu usage is `komorebic.exe` (after komorebic log command).

adam commented

@LGUG2Z commented on GitHub (Jun 19, 2024):

@starise fixed the issue with threads not being terminated for border and stackbar windows ^

@LGUG2Z commented on GitHub (Jun 19, 2024): @starise fixed the issue with threads not being terminated for border and stackbar windows ^

adam commented

@LGUG2Z commented on GitHub (Jun 20, 2024):

@KevinNitroG I'm guessing this might also have been the cause of your CPU temp issues 🤔

@LGUG2Z commented on GitHub (Jun 20, 2024): @KevinNitroG I'm guessing this might also have been the cause of your CPU temp issues 🤔

adam commented

@KevinNitroG commented on GitHub (Jun 20, 2024):

@KevinNitroG I'm guessing this might also have been the cause of your CPU temp issues 🤔

Do you think about reopening this issue, for anyone else having the same issue to find? Because I've just installed the latest version 0.1.27 and the CPU usage is not really positive. I'm staying at 0.1.25 for now...

@KevinNitroG commented on GitHub (Jun 20, 2024): > @KevinNitroG I'm guessing this might also have been the cause of your CPU temp issues 🤔 Do you think about reopening this issue, for anyone else having the same issue to find? Because I've just installed the latest version `0.1.27` and the CPU usage is not really positive. I'm staying at `0.1.25` for now...

adam commented

@LGUG2Z commented on GitHub (Jun 20, 2024):

the CPU usage is not really positive

I can't really make anything out of statements like these about CPU without hard numbers.

If you have CPU usage readings like this to share, or even better, comparative readings across different versions in similar conditions, it gives people something to investigate.

@LGUG2Z commented on GitHub (Jun 20, 2024): > the CPU usage is not really positive I can't really make anything out of statements like these about CPU without hard numbers. If you have CPU usage readings [like this](https://imgur.com/Ko3cyLZ) to share, or even better, comparative readings across different versions in similar conditions, it gives people something to investigate.

adam commented