Compiling can use an arbitrarily large amount of CPU, memory, and disk bandwidth. After all, if more of the critical resource were available, using it would all

Compiling can use an arbitrarily large amount of CPU, memory, and disk bandwidth. After all, if more of the critical resource were available, using it would allow compilation to complete faster, which would be a win. The beach ball occurs when some UI process does not service its event loop. This can be an issue with the process, or it can be caused because that process is contending for resources with the compilation processes. If the critical resource that's causing a beachball here is CPU, there's two very easy paths forward: either modify your compilation scripts to use fewer threads than the system has physical performance cores, or run the compilation at a higher nice level. In either case the UI process should be able to get CPU when it needs it and not beachball. The higher nice level is generally both the easier and more effective solution, since it will allow the compilation process to continue to use all cores when UI processes are not scheduled. If the critical resource is memory the system will page, which will turn the critical resource into disk bandwidth. Fixes specific to memory usage here are to get more memory (not really actionable), or to reduce parallelism on the build process. If the critical resource is disk bandwidth, this is the hardest problem to fix. To my knowledge MacOS doesn't provide good tools for managing disk priority. If the disk bandwidth being used is to access build-related files (source, object files, etc) rather than swap, one possibility is to use a thunderbolt-connected external SSD for the build artifacts, leaving the internal storage for swap and for the UI program. However, if your build process is using so many disk operations that it's starving a UI program, you're likely to see a performance hit going to a slower external SSD.