Performance issues when switching spaces

[booherbg]

When switching spaces I experience some lag that partially locks up the mouse.

When using OSX Keyboard shortcuts (like ctrl+left, ctrl+right), I experience a ~1 second performance hit that is pretty obvious. The main indicator is that the windows do not slide in smoothly, and my mouse locks up or lags.

This also happens if I click an app from the dock that is in a different space than I am focused, which causes a transition to that space.

When I use the yabai space shortcuts to jump immediately to a space, it's better but still laggy (mouse still partially locks up). I think the same issue is happening, but it's less obvious with yabai transition since there is no animation.

Is there a configuration I can do to minimize performance impacts? This is a pretty standard setup, using light window borders, some window gaps, and the status bar. I'm also generally curious if anyone else experiences this.

• OSX 10.14.6
• 16GB Ram, MacBook Pro 2012
• 8 spaces currently configured
• Only running Chrome, Slack, Spotify

PS: If I do brew services stop yabai the performance issues and mouse lockup goes away.

[booherbg]

After further investigation, this seems to be an interaction between yabai and ubersicht. If I quit Ubersicht (or yabai), the lagging goes away. This may be helpful for folks in the future.

So to conclude:
yabai only: no lag
ubersicht only: no lag
yabai + ubersicht: lag

Does anyone else experience lag with ubersicht?

[dominiklohmann]

What code are you running for Übersicht that interacts with yabai and vice versa? How and when are you triggering things?

[booherbg]

@dominiklohmann I am only running default Ubersicht, with no widgets. I only installed it and hadn't even installed any plugins yet. Stock on everything, except I do have the yabai status bar turned on.

Triggering with the keyboard shortcuts (mission control and skhd, as noted earlier)

[dominiklohmann]

I can't reproduce this at all, but to be fair my computer is quite a bit newer, so maybe this is just an issue on slower machines. It'd be nice if someone who has an older machine and happens to stumble upon this issue could verify that this is an actual issue.

[booherbg]

@dominiklohmann ok so i have an update that may be related to this.

I had to stop using yabai for a few days because the performance started to get to me. Basically with 8 spaces across 2 monitors and a full development environment up, I was seeing a delay of up to 2 seconds if I switched spaces too quickly. Basically its like yabai has to finish 'redrawing' windows each time a space is switched, which pauses the rest of the yabai functionality.

Then I went on a journey to just find some solution that gives me the absolute minimum that I need:

• Keyboard driven 'throw to specific space number'
• opt-in full screen or tiling

I spent the weekend pretty bummed out since nothing comes close to the functionality that yabai provides (its basically perfect, except for my performance issues).

So this morning I had an idea, what if I turn off everything in yabai and selectively add back in functionality as I need it?

So right now I have yabai running but only managing a single space (my 'terminal' space). This gives me back all the space management and window functionality, and is blazingly fast. It's a really nice compromise.

The one thing I notice is that even when I switch to my terminal space, I see the 'borders' of my terminals flashing as yabai attemps to re-draw them, even though nothing has changed.

The other main challenge is that I would still love a way to force all of my other windows (chrome, slack, etc) to run at max size, even if I have to do it manually by binding yabai -m space --balance

So based on this I have two comments:

• Is there a way to stop yabai from updating so often? I'm sure this is the root cause of my performance issue. Even if I could 'manually' trigger yabai to "retile" a space after I load a new window, that would be an OK compromise (because then I could still keep the fast performance)
• Is there a way to ask yabai to only run when a new window is formed? Or to allow yabai to manage a space but turn it off so that it only runs when I manually ask it to? Ideally if I have my terminals managed by yabai (tiled), in 90% of other cases all I want is a reasonable way to have my windows go full screen. I can run yabai -m space --balance on my managed spaces, but that doesn't help me when I only have one managed space (due to performance concerns).

Just curious if you have any thoughts! Hopefully this is helpful. Keep up the great work with yabai, there's nothing else like it that gets me closer to my i3 experience.

[koekeishiya]

The one thing I notice is that even when I switch to my terminal space, I see the 'borders' of my terminals flashing as yabai attemps to re-draw them, even though nothing has changed.

By borders, do you mean the active and inactive window borders provided by yabai? If yes, how is the performance if you disable all window borders: yabai -m config window_border off

[booherbg]

The one thing I notice is that even when I switch to my terminal space, I see the 'borders' of my terminals flashing as yabai attemps to re-draw them, even though nothing has changed.

By borders, do you mean the active and inactive window borders provided by yabai? If yes, how is the performance if you disable all window borders: yabai -m config window_border off

Whoa. Good tip. I disabled both borders and window shadows, and I see a significant performance boost. It's almost instant now. I test this by holding down my mod key and running my finger back and forth along my number keys :)

This is great! Its a significant increase and at first pass my system feels very responsive compared to before.

[koekeishiya]

That's great. Does it also run at a usable speed if you enable tiling on all desktops (if that is what you ideally want, of course)?

So the thing to note is that I have not tackled the problem of performance thus far in development, as the focus is primarily robustness and ironing out weird macOS quirks.

I try to make sure that I don't deliberately write slooow code, but it's not like I have actually done any profiling yet (mostly due to lack of good tools, instruments barfs for some reason and won't actually let yabai run properly).

[booherbg]

That's great. Does it also run at a usable speed if you enable tiling on all desktops (if that is what you ideally want, of course)?

So interestingly, with everything back on it feels snappy now. All windows managed! This is great. Thank you! I'll investigate shortly to see if this may also be the culprit of the original performance issue w/ Ubersicht.

So the thing to note is that I have not tackled the problem of performance thus far in development, as the focus is primarily robustness and ironing out weird macOS quirks.

I try to make sure that I don't deliberately write slooow code, but it's not like I have actually done any profiling yet (mostly due to lack of good tools, instruments barfs for some reason and won't actually let yabai run properly).

Totally. First make it work, then make it right, then make it fast right? :)

[booherbg]

OK so with Ubersicht running (stock, no widgets, and coffee widget is loaded but not running):

• I no longer get the super lag, where the mouse lags
• I do get signifiant performance impact when switching spaces, similar to borders on but ubersicht off (so borders on + ubersicht --> lag and mouse stutter).

So to summarize:

• Ubersicht on + borders/shadows on --> very bad performance and mouse stutter
• Ubersicht off + borders/shadows on --> bad performance (but no mouse stutter)
• Ubersicht off + borders/shadows off --> good performance (no noticeable delay in switching spaces quickly)

[koekeishiya]

Closing this as borders have been removed for various reasons not related to performance, see #487

[spaceunifyfifty]

One cause of slow yabai commands is actually skhd being slowed down by fish shell. I solved it here #2448