Improving perfomance when working WM

[mocki-toki]

[ALinuxPerson]

If I am interpreting this title correctly, this is in regards to the high CPU usage from Barik while it is opened, right?

If this is the case, then yeah this a huge blocker for me to start using Barik as a daily driver replacement for sketchybar.

I haven't done any formal profiling yet, but I'm pretty sure it is due to calling the main provider process and parsing the JSON from it. It shouldn't take that much CPU usage, considering that it is only done 10 times a second (0.1 second timer interval), but it does unfortunately, for both yabai and aerospace.

I wonder if it is possible to instead rely on events from the provider process instead of polling constantly. I've done some experimenting with a branch in my fork, but I haven't actually implemented the event-based protocol yet in either aerospace or yabai (I can only test aerospace right now, since that's my daily driver window manager, recently switched away from yabai) but I will do it in the near future.

Also, we could take inspiration from how sketchybar does it with either aerospace or yabai. I have no idea how they manage to do the usual menu bar stuff with minimal CPU usage as possible, but it's worth looking deeper into.

[mocki-toki]

If I am interpreting this title correctly, this is in regards to the high CPU usage from Barik while it is opened, right?

If this is the case, then yeah this a huge blocker for me to start using Barik as a daily driver replacement for sketchybar.

I haven't done any formal profiling yet, but I'm pretty sure it is due to calling the main provider process and parsing the JSON from it. It shouldn't take that much CPU usage, considering that it is only done 10 times a second (0.1 second timer interval), but it does unfortunately, for both yabai and aerospace.

I wonder if it is possible to instead rely on events from the provider process instead of polling constantly. I've done some experimenting with a branch in my fork, but I haven't actually implemented the event-based protocol yet in either aerospace or yabai (I can only test aerospace right now, since that's my daily driver window manager, recently switched away from yabai) but I will do it in the near future.

Also, we could take inspiration from how sketchybar does it with either aerospace or yabai. I have no idea how they manage to do the usual menu bar stuff with minimal CPU usage as possible, but it's worth looking deeper into.

I also believe that the problem of high CPU consumption is related to the constant polling of data. I'm currently experimenting with yabai triggers and conducting testing, I think I'll fix it in the next update.

[wzxu]

Idea from one of Sketchybar's plugins for Aerospace: Since sketchybar has a CLI command, they can just trigger an event automatically from Aerospace's built-in exec-on-workspace-change hook (not sure if something like this exists for yabai since I don't use it). Simple and clean. I'd say it's worth looking into for a similar solution.

[mocki-toki]

Idea from one of Sketchybar's plugins for Aerospace: Since sketchybar has a CLI command, they can just trigger an event automatically from Aerospace's built-in exec-on-workspace-change hook (not sure if something like this exists for yabai since I don't use it). Simple and clean. I'd say it's worth looking into for a similar solution.

Thank you for the proposed solution! It will definitely work, but this approach doesn’t align with the philosophy of barik, as it requires manual intervention and doesn’t work out of the box.

[nikitabobko]

as it requires manual intervention and doesn’t work out of the box.

I very much respect no-manual-setup mantra. It's not possible to subscribe to AeroSpace callbacks without modifying the config, and it is a valid request nikitabobko/AeroSpace#1514