It uses near 100% CPU for around 3 minutes on a full compile in my project. But the actual problem is when I change safety settings triggering a recompile it locks input for a while, 10 seconds or so, but up to a minute! After that 10-60 seconds, unity is not as responsive as it’s still compiling with as much CPU as it can get its hands on.
So, if burst is off with safety setting on, and I want to do a test with burst on, safety off, I have to enable, wait 10-60 seconds then toggle safety, and start recompiling again.
Now, this alone wouldn’t be a big deal, but you bring me to my second point with your question about rarity of switching.
In an ideal world, burst would just stay on 24/7, especially with break points working in burst context now. But we do not live in such a world. We live in a world of alphas, betas, experimental features. Burst doesn’t always work, so we toggle to test (even if just to eliminate burst as a suspect), we re-enable after restarting editor with a cleared burst cache, sometimes we just want to see the performance difference of something without recompiling burst attributes.
Finally, even with burst maturing a lot, there are still cases where the burst cache can get corrupted. Interrupting a compile with a new compile adds to that risk, especially when you are going through cycles and cycles of editor restarts and Burst cache clears, and just went to minimise problems as much as possible.
At the end of the day though, I would have saved a LOT of time lately if I could toggle safety before burst with the huge amount of editor crashes I’ve been getting and trying to debug. Even the annoyance of that 10-60 seconds is enough of a reason though imo.
The only reason I’m posting is because a use case was compelling enough (it irritated me enough) to bring me here, and a “me too” from my co-worker sealed the deal.