Copyright © 2026 Unity Technologies
These increased compilation times, when the Burst package is installed, are actually expected (but obviously not ideal). Specifically, the increased compilation times come from the extra IL postprocessing that happens when the Burst package is installed. And the reason why {{--burst-disable-compilation}} doesn't make any difference is that this IL postprocessing always happens, even when actual Burst _compilation_ is disabled. Because of the way incremental builds and caching works, it's always necessary to run Burst's IL postprocessing, even when Burst compilation is disabled. The repro steps - e.g. triggering recompilation of an assembly that is referenced by 99 other assemblies - represent a sort-of worst-case for this, because all 100 of these assemblies need to be IL postprocessed.
How to reproduce:
1. Open the “U6CT.zip“ project
2. Press Assemblies > “Create 100 Assemblies” in the Toolbar
3. In any of the generated Assemblies (in “Assets/Assets/Core”) make any change to trigger a Script Reload
4. Observe the loading times
5. Install the Memory Profiler package from the Package Manager (to install the Burst package as a dependency)
6. Repeat step 3
7. Observe the loading times again
Expected result: The second Script Compilation Time takes roughly around the same time as in step 4
Actual result: The second Script Compilation Time takes double or more time than in step 4
Reproducible in: 1.8.0, 1.8.19 (2022.3.58f1, 6000.0.38f1, 6000.1.0b6, 6000.2.0a3)
Reproduced on: Windows 11 Pro (23H2)
Not reproduced on: No other environment tested
Note: It’s increasingly noticeable with more Assembly scripts are generated
Issues you vote on will appear here