Unity spawns a lot of Unity Shader Compiler processes when building a Player. Unity spawns so many of these processes, that the PC is pretty much unusable, while the build process is running.
This is not a problem on a dedicated build machine. It’s however a problem when one would like to continue to work on the same machine, which is my typical work-scenario. When I trigger a build in Unity, I want to do other work on the same PC, while Unity is building the player.
However, since so many Unity Shader Compiler processes are running, the system has almost no resources left that allow to work in other applications. All cores pretty much go up to 100% utilization.
I would like to suggest an option, where one can limit the number of Unity Shader Compiler processes, so that the system has enough resources to allow me to continue to use the PC for other tasks, while the build process is running.
You can limit the number of job worker threads when starting Unity by passing a -job-worker-count command line parameter. This will also limit the number of shader compiler instances.
We have what you ask for in the backlog
Yes, https://docs.unity3d.com/Manual/EditorCommandLineArguments.html but it does not quite go into detail what that argument does (does it only affect number of jobs for C#/Engine threading systems? Shader compilation? Lightmap baking? Player build? Something else? etc.)
The heuristic for the number of worker threads might need to be optimized… My 7590x w/ 32GB of RAM is memory bound during shader compilation instead of CPU bound.
A slight decrease in worker threads using -job-worker-count seems to yield improvements in shader compilation time. I’m not keen to delete my library folder for a definitive test, but it raises an interesting question: what is the heuristic for spinning up shader compilers? Is it based on CPU cores or does it account for total memory overhead?
