Delay/freeze when switching focus & workspace

fmasa commented 8 months ago

Hi! Thanks for all the new features.

After updating to 0.8.0, I had AeroSpace disabled before I fixed the config file and I noticed that when AerosSpace is enabled there is a noticeable delay (I have no measurements, but it feels like hundreds of milliseconds at least) when either moving focus or changing workspaces. This also happens when I focus windows via cmd+tab, doing this without AeroSpace is instantaneous.

I know it's still beta, but I wanted to ask:

Do other people experience this delay or am I missing some configuration
Is this a performance issue in AeroSpace or some inherent limitation of Accessibility API?
Is there any way to collect logs/diagnostics to find out more?

I'm on M1 Pro + Sonoma.

I'm not trying to bash AeroSpace - the feature set is great and I use it as a daily driver, but the MacOS felt laggy for a while and now I found out it's only when using AeroSpace and I want to help to make it better.

Note by @nikitabobko

Related: #242

nikitabobko commented 8 months ago

(1) How many windows do you have opened? (you can use aerospace list-windows --all | wc -l) (2) Does the AeroSpace still behave poorly if you restart the app?

I saw on my colleague's machine that AeroSpace may behave poorly if there are unreasonably many windows opened (maybe 100 or even more, we didn't count)

I tried to open 20 windows and it performs well, I don't see any delay compared to when AeroSpace is not running

Do other people experience this delay or am I missing some configuration

I can't see any delay on my machine (M1 Pro + Sonoma). I normally don't have more than 10 windows opened

or some inherent limitation of Accessibility API?

I heard several times that Accessibility API is slow. Though, I can't confirm it yet. The only slowness of Accessibility API I noticed is when some apps block their UI thread in some special way (I couldn't reproduce the slowness when I wrote a small app that displays a simple window and blocks the UI thread).

For example, Spotify and Firefox sometimes block the UI thread in a special way for several seconds when I try to quit (cmd+q) either of them, Accessibility API is blocked by these apps until they finally quit. I've not yet debugged this problem. IntelliJ IDEA sometimes blocks the UI thread in a way that blocks accessibility API (I don't know the reproducer yet)

(3) Some of the apps that you are running may have similar problems, so you can try to quit apps one by one to see when AeroSpace delay goes away

Kamyil commented 8 months ago

Hi! I'm experiencing this issue on my Macbook Pro 14 with M1 Pro on macOS Sonoma, but a little bit differently. When I'm not switching workspaces for a while, then first workspace switch has a little bit of delay (it's hard to measure that, I'm front-end dev dealing with transitions/animations day-by-day, so my eyes are a little bit trained, but not perfect ofc)

but when I switch and then immediately switch again and again (and so on) it takes noticeably less time to switch. So it behaves like it does some kind of cool start on first switch and then it runs faster after the first switch, creating illusion that it has some delay on first switch

If there was some logging tool that would allow to measure the time to switch workspace, then I could attach such log file to this comment. It's actually hard to record on video without some keys recording (but I can try ofc)

extra info I have 5 workspaces with 1 window per workspace

F-TD5X commented 7 months ago

Hi! I'm experiencing this issue too on M1 Pro MBP.

And the situation only happened when I starting debug an application with idea.

Seems this is what @nikitabobko said but a stable reproduce way. (at least for me)

IntelliJ IDEA sometimes blocks the UI thread in a way that blocks accessibility API (I don't know the reproducer yet)

Are there any way I can offer more infos?

fmasa commented 7 months ago

I have IDEA opened 90+% of time, so that might be a culprit 🤔

fmasa commented 7 months ago

I encountered it a few times again and killing IntelliJ IDEA fixes the issue. It seems that AeroSpace commands are queued because of all the workspace switching I tried to do when it hung are quickly applied after the IDEA is killed.

nikitabobko commented 7 months ago

The potential fix is to send accessibility requests to different applications from different threads. This way, if one application hangs, it won't affect others. But I don't know whether Apple accessibility API is thread-safe (My intuition says that it's probably not)

Also, I'm curious whether yabai/Amethyst have this problem (obviously, if they have this problem, it's not as severe for them, because they use native macOS spaces, but AeroSpace needs to constantly move windows to the bottom right corner back and forth)

cannonrush commented 6 months ago

Somewhat related, since it also introduces a noticeable delay: is it possible to execute all commands (such as changing focus or switching workspaces) on key press instead of key release?

lucax88x commented 5 months ago

would also be a good idea to "buffer" these commands?

so let's say I'm in workspace 1 and I do:

workspace3
workspace1
workspace1
workspace3

but nothing happens because it's hanging somewhere, so instead of seeing 3 workspace changes after some seconds, just buffer and run the last one?

Btw to me happens when I swap to different monitor setup (office => train => home)

And I also 8 workspace, 2 intellij products (rider and datagrip)

nick-potts commented 4 months ago

I've been getting it quite a bit lately.My cpu is often maxed out at 100%, often by a bash process running in my IDEA terminal, and my window management then has a 4-10s delay.

It's easily replicable with stress -c 16 (or whatever cores your Mac has) installed from brew. Interestingly, from a regular terminal this same behaviour doesn't seem to happen.

Also, I'm curious whether yabai/Amethyst have this problem (obviously, if they have this problem, it's not as severe for them, because they use native macOS spaces, but AeroSpace needs to constantly move windows to the bottom right corner back and forth)

I believe from memory they did, but "spaces" was always fine under heavy cpu load.

gohma231 commented 3 months ago

I get this a lot as well. I frequently have high CPU load on my machine and aerospace is very delayed in switching.

diogox commented 2 months ago

Same here!

The 4-10s delays are a real struggle :(

Never made the connection to IntelliJ, but can confirm: I daily Goland (it's IntelliJ under the hood) and have been noticing huge slowdowns - potentially as I open more instances(?) - but mostly when I have > 1 monitors connected.

nick-potts commented 2 months ago

Just have to run stress -c 16 in the integrated terminal in an IntelliJ app and you'll be in a world of pain.

gempir commented 2 months ago

Also constant IntelliJ user. Sometimes I notice like 10-15s delay and for some reason quitting Aerospace and reopening does help a bit.

Hritik14 commented 2 months ago

Lag with intelij running is a lot that it hinders usability. when I switch to a different workspace, I see my background for a few seconds then all the windows render on the workspace. This is also visible when IDEA is not running but it is very quick.

kahnclusions commented 1 month ago

I've also noticed this issue, and I'm not an Intellij user. Sometimes I can narrow down a specific app (for example I noticed Swift Mail causes a lot of lag), but sometimes I just have Firefox, Wezterm, and Discord open and still get a 5-10 second lag. Restarting Aerospace helps for a while until it comes back.

It's a pity to see that issue popping up because I really love Aerospace and have been daily driving it for the past 2-3 months!

chinedufn commented 1 month ago

I am able to reliably reproduce the problem.

After dealing with the delaying or freezing for my first two or so weeks of using aerospace, I went a couple of weeks in a row without any delaying/freezing.

After that couple of weeks without any performance issues I ran my codebase's test suite, which is CPU intensive.

Aerospace workspace switching immediately became slow, and remained slow even after my CPU load went back to 1-2%.

Once I restarted it aerospace, everything was fast again.

Looking back, for the two or so weeks where it was fast I had:

Quit aerospace at the beginning of that 2 week period because I was restarting my computer
Not done anything CPU intensive for a couple of weeks
As soon as I did something CPU intensive, it became slow again. Restarting aerospace made workspace switching fast again.

The above suggests that this issue is not directly related to what applications you are running.

The slowness begins as soon as you do something CPU intensive, regardless of what application caused it.

People are reporting that they notice the problem when running intellij.

I suspect that this is because intellij is something that people use to do CPU intensive things.

Given that the problem immediately goes away once you restart aerospace, I'm inclined to believe that aerospace is capable of either fixing or working around whatever the problem is.

For instance, in the worst case aerospace could detect unusual slowness and do whatever it does when it restarts. (I am not suggesting that this is a good idea, just pointing out one brute force solution).

In the best case, we identify what aspects of aerospace could at all be related to this issue, narrow down the root cause, and fix it.

In summary:

the above describes how to reproduce this issue
the issue seems solvable within aerospace, be it using a brute force solution or a more elegant one

Performance issues have been on an intel mac.

2.4 GHz 8-Core Intel Core i9
2019 MacBook Pro

graywolf-s1 commented 1 month ago

Happens to me regularly with GNU Emacs. Every time it is in blocking operating (it is single thread, so it tends to happen), it is not possible to switch workspaces. Reproduction is trivial, run M-x sleep 5 and try to switch workspace.

gempir commented 1 month ago

Today I found it goes so far that Activity monitor says Aerospace is not responding and if you hover the menubar item of Aerospace you get the beachball. And you could do zero actions with Aerospace.

This happend because IntelliJ somehow also got stuck and had to be force-quit. I even restarted Aerospace (while IntelliJ was still in its broken state) and Aerospace was barely responsive only resizing some windows, switching workplaces didn't work at all.

Only fully force quitting IntelliJ brought life back to Aerospace.

nikitabobko commented 1 month ago

No need to report about applications that block macOS AX API (such as IntelliJ, or Emacs sleep 5). It's known problem and I can reproduce it. There are several directions to investigate

Make use of AXUIElementSetMessagingTimeout, and implement some kind of backoff strategy for applications that hang
Dedicate a thread for each application and issue AX requests from them (IDK if it's a thread-safe)

Until I have time to dig into this problem, everyone else is welcome to do so

GuiltiTer commented 1 week ago

Same issue here! I have an M2 Pro machine. Today, with the Telegram desktop app, Kitty, and IINA windows, I opened. Killing all applications one by one and restarting the Aerospace didn't fix the workspace switch lagging (sometimes not responding in a few minutes). Killing the Finder did the job, though.

nagy135 commented 1 week ago

i also have hard time pinpointing what the issue is ...yesterday i had like 3sec freezes switching desktops and closed everything but browser and alacritty and it fixed it. For me its one of (or all combined) BambuStudio, Blender, Spotify desktop.

emielvangoor commented 1 week ago

I am experiencing the same issues. Not using Intellij but i suspect its due to the Arc browser. Aerospace is snappy in the beginning but quickly gets very, very slow, almost unusable. Restarting Aerospace does the trick.

M1 Pro on Sequoia 15.0

Edit; It seems when I disable JankyBorders its working better. Time will tell.

kahnclusions commented 1 week ago

I think we know what the root of the issue is, based on this comment, the open question at this point is what can be done to solve it.

graywolf-s1 commented 1 week ago

2. Dedicate a thread for each application and issue AX requests from them (IDK if it's a thread-safe)

If it would fail to be thread safe, maybe it would also be possible to spawn a child process per application and issue AX requests to from that sub-process. Then the main AeroSpace process could queue them work and collect the responses in non-blocking way.

I can imagine it would complicate the architecture a lot, but I guess it should work?

emielvangoor commented 5 days ago

I am experiencing the same issues. Not using Intellij but i suspect its due to the Arc browser. Aerospace is snappy in the beginning but quickly gets very, very slow, almost unusable. Restarting Aerospace does the trick.

M1 Pro on Sequoia 15.0

Edit; It seems when I disable JankyBorders its working better. Time will tell.

After full working day I can say this did the trick, disabling JankyBorders fixed all issues for me..

michaelessiet commented 3 days ago

I experience this issue even without jankyborders. I think the threading thing might be the issue because once I restart my computer aerospace works fine at least until I get a couple apps running for an extended period of time (a few days) then I experience the lag.

nagy135 commented 3 days ago

i too see the same, but whenever it starts degrading, all i need to do is close all the apps (excluding terminal and browser) so probably some apps are causing this to be worse but it always fixes it for me. Then its almost instant for days, then there seems to be a point where it suddenly starts degrading again and turns from fraction of second to few seconds. Then closing apps solves it again.

nikitabobko / AeroSpace

Delay/freeze when switching focus & workspace #131