Unresponsive when ninja is compiling a project (i.e. when CPU usage spikes)

[starptr]

Describe the bug

When using ninja to compile a c++ project, it uses multiple cores & CPU usage spikes. The system is overall slower, but alt-tab is uniquely unresponsive / laggy.

Screenshots / video

The alt-tab UI does not appear when pressing alt-tab. Sometimes, the keypress is registered (albeit the visual UI only appears after multiple seconds), but the depress is not registered so the UI stays on-screen.

Steps to reproduce the bug

1. Clone any large c++ project that uses the ninja build system.
2. Run the corresponding ninja -C <dir> command to build the project.
3. Press alt-tab to attempt to trigger alt-tab.
4. Notice that it is exceedingly slow when compared to other applications.

[lwouis]

I've done extensive profiling with Instruments in the past to get to current performance. AltTab UI rendering is pretty fast (as fast as AppKit can go) and most importantly, most of the OS calls are made async in background threads so the UI doesn't wait to paint.

It may be possible to replicate the CPU pressure of ninja using some shell utility that does CPU stressing.

Also to share: AltTab runs as some kind of background app (no Dock icon), so i've already implemented a number of extra things to avoid Sudden Termination, Automatic Termination, Power Nap, or get CPU throttle by the OS since it's a background app.

AltTab is very easy to run locally from source. It's 2 CLI commands away. You may try to profile it yourself if you have the skills to help here

[XInTheDark]

AltTab runs as some kind of background app (no Dock icon), ...

AltTab is very easy to run locally from source. It's 2 CLI commands away.

Ah yes, I've been wondering about that. Why didn't you make AltTab run like most apps do? Is it because it uses way more CPU, etc.? or was it just to make it easier for people to run it, like what you said about running it locally?

[lwouis]

@XInTheDark there are 2 distinct topics here:

1. Running the app from source. This is useful if someone wants to develop the app, debug it, or profile it. They can git clone the project, then run the 2 commands listed on the Contributing page and run the app from source.

2. The app is a background app. I went with this so that the app has no Dock icon. I only want the app to live in the menubar. This is a utility app, similar to others like Spectacle, Hookshot, Contexts, Witch, etc. It helps with window management; it does what the OS / Mission Control should probably do natively. It's not a normal app: you don't open it and use it, exploring its contents, then hide it away of close it. Instead it's always running in the background.

[lwouis]

@starptr could you please share a link to a project that I could use to reproduce the issue?

I have tried using stress with the following parameters stress -m 16 -c 8 -i 100, which is pretty intense on my machine, and yet AltTab is very responsive and snappy.

Furthermore, in the latest release of AltTab, I have changed the way AltTab is launched by launchd (when launched at login). That may have been the reason AltTab was sluggish for you in the first place, not AltTab itself, but essentially low OS prio.

Could you please confirm that on the latest version of AltTab, you can reproduce the issue? And if yes, please share the project so I can try with ninja. Even stress -c 16 doesn't impact AltTab for me.

[starptr]

Unfortunately I no longer have a suitable machine to reproduce this with (and the original project I experienced this problem in is also unfortunately proprietary). I’ll let you know once I get a mac machine and if I can find a repro that’s useful for debugging this issue!

[XInTheDark]

I have noticed this issue as well. For example, when an IDE is starting, it takes up most of my CPU, and AltTab tends to become unresponsive when I activate it.

[XInTheDark]

The difference is barely noticable as it only occurs for a few seconds, but still happens nonetheless.