Delay/freeze when switching focus & workspace

[fmasa]

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]

(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]

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]

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]

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

[fmasa]

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]

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]

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]

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]

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]

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

[diogox]

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]

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]

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

[Hritik14]

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]

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]

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:

1. Quit aerospace at the beginning of that 2 week period because I was restarting my computer

2. Not done anything CPU intensive for a couple of weeks

3. 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]

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]

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]

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

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

Related yabai discussions: koekeishiya/yabai#2377 koekeishiya/yabai#599 koekeishiya/yabai#600

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

[GuiltiTer]

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]

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]

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.

[michaelessiet]

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]

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]

In 0.15.0, I added a low effort commit to set AXUIElementSetMessagingTimeout to 1 second.

It won't resolve the problem, but should avoid complete freezes caused by 3rd party apps

[KasselMarc]

I also experience aerospace getting slower over time, not freezing completely but definitely some 1-2s delays having around 10 windows at 10 different work spaces open. I don't use JankyBorders.

[ronaldsuwandi]

In 0.15.0, I added a low effort commit to set AXUIElementSetMessagingTimeout to 1 second.

It won't resolve the problem, but should avoid complete freezes caused by 3rd party apps

Used the latest 0.15.2 but still face the similar problem. It's particularly prevalent when having high CPU usage (IntelliJ compiling). Switching between workspaces can take seconds. Really hope this get resolved soon 🙏

[raisjn]

I was able to reduce (read: eliminate) the multi-second stalls by pushing work to a separate thread and can now push to 100% CPU without getting any slow down in Aerospace. I test drove it for the past day and it's working well so far. Will see if any problems surface over the next couple days but it makes me optimistic that this problem is capable of being solved.

[saivan]

I seem to be getting the exact same problem from chromium based apps. Happens when I push CPU usage on both Arc and VSCode. Delays can be 20 seconds. I'm on an M1 Max most of the time. Also have to say @nikitabobko this app is awesome! Great idea and great execution :)

[jack4git]

I missed this ticket and created #604 -- lots of details there on my experience and config, same issue I'm sure.

[clarsen]

i'm seeing that the detectNewWindowsAndAttachThemToWorkspaces is slow, but on further delving into it, the iteration over apps MacApp.get() construction/population is slow for just one of the long running apps. When I closed that app, everything sped up again.

[nick-potts]

I was able to reduce (read: eliminate) the multi-second stalls by pushing work to a separate thread and can now push to 100% CPU without getting any slow down in Aerospace. I test drove it for the past day and it's working well so far. Will see if any problems surface over the next couple days but it makes me optimistic that this problem is capable of being solved.

Do you mind pushing your changes to your fork - I'd love to test drive as well.

[raisjn]

@nick-potts: i've been moderately busy, but i started a discussion with a list of approaches I've tried: #655. I will see when I can find time to polish the code a little and put it in a fork - I have several modifications that are separate from this and would need to extract just this change.

[liamaharon]

@raisjn appreciate you working on this! I will gladly offer 500 USD (paid in ETH) if you merge a fix here that keeps aerospace responsive while my CPU is saturated compiling code.

[raisjn]

@nick-potts: I put a link to a branch in #655, please try it out and remember to enable it with new-window-detection-timeout = 100 config option in aerospace.toml. There are several potential bugs - see the listed ones in #655 and if you notice others, please add them to the discussion. Please update us if it works for you

@liamaharon: thank you for the offer, i appreciate the thought but can't accept - feel free to sponsor aerospace instead 🫶

[zapoutix]

Hello @raisjn
I just compile the branch "dev/okay/2024_11_02_less_cpu_lockups" and add new-window-detection-timeout = 100 in config file.
When Godot is open is still laggy when switching workspace.

[liamaharon]

@raisjn I've been running dev/okay/2024_11_02_less_cpu_lockups with new-window-detection-timeout = 100 today.

Some lag is still noticeable, but far less severe or frequent, much more usable now! Thank you so much!!

I'll keep daily driving it and let you know if I bump into any issues.

[zapoutix]

@raisjn i will have a try,
with the "dev/okay/2024_11_02_less_cpu_lockups" version i got a crash, never happened with the 15.2,

##### AeroSpace Runtime Error #####

Please report to:
    https://github.com/nikitabobko/AeroSpace/issues/new
    Please describe what you did to trigger this error

Message: Windows always have parent
Version: 0.0.0-SNAPSHOT
Git hash: bd23ebece513751c0ca00a18a345bddf1f75bb41
Coordinate: /Users/mattal/Downloads/AeroSpace/Sources/AppBundle/tree/Window.swift:7:72 parent
recursionDetectorDuringFailure: false
cli: false

Stacktrace:
0   AeroSpace                           0x00000001005931d0 $s6Common6errorT_4file4line6column8functionxSS_SSS2iSStlF + 744
1   AeroSpace                           0x0000000100436c28 $s9AppBundle19tryOnWindowDetected_7startupyAA0E0C_SbtF + 160
2   AeroSpace                           0x0000000100436d90 $s9AppBundle9MacWindowC3get3app02axD07startupACSgAA0cA0C_So14AXUIElementRefaSbtFZyyScMYccfU_ + 16
3   AeroSpace                           0x000000010041eb5c $sIegh_IeyBh_TR + 28
4   libdispatch.dylib                   0x000000019211a8f8 _dispatch_call_block_and_release + 32
5   libdispatch.dylib                   0x000000019211c658 _dispatch_client_callout + 20
6   libdispatch.dylib                   0x000000019212af68 _dispatch_main_queue_drain + 980
7   libdispatch.dylib                   0x000000019212ab84 _dispatch_main_queue_callback_4CF + 44
8   CoreFoundation                      0x00000001923f4e60 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
9   CoreFoundation                      0x00000001923b4a4c __CFRunLoopRun + 1996
10  CoreFoundation                      0x00000001923b3bc4 CFRunLoopRunSpecific + 588
11  HIToolbox                           0x000000019d823f64 RunCurrentEventLoopInMode + 292
12  HIToolbox                           0x000000019d829d54 ReceiveNextEventCommon + 636
13  HIToolbox                           0x000000019d829eb8 _BlockUntilNextEventMatchingListInModeWithFilter + 76
14  AppKit                              0x0000000195edfa08 _DPSNextEvent + 660
15  AppKit                              0x000000019681fe0c -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688
16  AppKit                              0x0000000195ed2ae0 -[NSApplication run] + 480
17  AppKit                              0x0000000195ea9364 NSApplicationMain + 888
18  SwiftUI                             0x00000001c0558340 $s7SwiftUI6runAppys5NeverOSo21NSApplicationDelegate_So11NSResponderCXcFTf4e_nAA07TestingdG0C_Tg5Tm + 160
19  SwiftUI                             0x00000001c09c8ee4 $s7SwiftUI6runAppys5NeverOxAA0D0RzlF + 84
20  SwiftUI                             0x00000001c0d41f24 $s7SwiftUI3AppPAAE4mainyyFZ + 224
21  AeroSpace                           0x00000001003ba474 main + 36
22  dyld                                0x0000000191f4c274 start + 2840

[raisjn]

@zapoutix: thanks for reporting! i'm familiar with this crash :'( - see the update in #655 - can you move your comment + future comments on behavior of the patch to #655? (same for anyone else discussing the patch)

(PS: I pushed a change to ignore this error but want to figure out the correct long term change)

[nikitabobko]

Today I received a very generous $500 donation via GitHub Sponsorship from @liamaharon. I didn't want for this to go unnoticed, I appreciate the support, thank you! It's the highest individual sponsorship I received, so it makes it clear how important this issue for you.

As for the issue, nothing significantly changed since my last update #131 (comment)

I understand the importance of this issue. Discussions, hacks people put in AeroSpace sources and the $500 donation make it clear. But I won't be giving any promises. The issue is fixed when it's fixed if it's fixed at all. Thanks everyone for your understanding

---

The core architecture of AeroSpace is built around what I call refreshSession. It's an idempotent procedure that is run on every relevant event from macOS or the user itself (e.g. keybind). On every refreshSession, AeroSpace checks for newly appeared windows, checks that windows are still in the right position, and pushes them down the macOS throat in the right position.

This approach makes sure that we don't rely on reliability of macOS events being delivered to AeroSpace at all or being delivered in the right order (yes, macOS can just drop the event and not deliver it to apps, or if it does deliver it, it will very likely be in inconsistent order). Until macOS sends events that at least approximately look like something reasonable, AeroSpace can provide a reliable experience. I was pissed off by how often some other window managers loose track of windows, so I went with this hard approach, and very happy about it. Hopefully, you notice that AeroSpace never looses track of windows.

<rant>I took a shortcut and didn't implement the detection of closed windows in the same idempotent manner, because when the screen is locked, closed windows become indistinguishable from non-closed windows. Unironically, Apple decided to break specifically kAXUIElementDestroyedNotification event in Sequoia #445, ughh</rant>

The flip side of the "idempotent"/"recheck the whole world every time" approach is performance. But I think it can be optimized, it just something that needs to be explicitly worked on, and worked very accurately without harming the correctness. I never spent time to properly optimize AeroSpace and macOS communication, so far I've been concerned only about the correctness and reproducibility (but still managed to get bitten by Sequoia #445).

Thanks to @raisjn for doing the performance experiments. The debouncing approach makes sense. The refreshSession may be called too often when a lot of things happen on the screen (e.g. when you switch the workspace), and given the idempotent nature of refreshSession, debouncing the whole session becomes trivial and may increase the app responsiveness. I don't agree with the specifics of implementation, but the general idea makes sense, thanks for your experiments. I will consider "the debouncer" approach when start working on performance.

Another known problem that I realized is that AeroSpace cares too much about correctness for invisible windows, and makes too much accessbility API requests because of that #545

As correctly pointed by @raisjn, please discuss the details of @raisjn fix in #655

Please, restrain from casually commenting in this issue, since it becomes unnecessarily long. If you want to say something, please say something that we don't know already.