When a project becomes large, many operations within the Editor can become very slow, especially the code compilation speed.
If there could be a configuration option that allows the Editor to ignore certain folders within the project (for example, excluding all art resource folders and only keeping the code), it would significantly improve the Editor’s responsiveness.
This configuration is different from the Hidden Assets mentioned in the Special folder names documentation. It does not require specific file naming conventions, only takes effect locally for the user, does not sync to version control systems, and does not affect other team members.
You cannot exclude code folders for obvious reasons. If code is missing, compilation will fail.In the future ie next tech generation we will see domain reload go away. That‘s the slow part, not compilation.
You can speed up compilation with appropriate use of assembly definitions to a degree, but too man could also make it worse. There‘s also profiling the editor because more often than not editor scripts in particular are terribly inefficient and could contribute significantly to the process.
And then there‘s the hardware. Spending $1,000 on an upgrade can be cost efficient in the long run.
Of course, I won’t exclude the code folder. As mentioned in the previous example, I want to remove the art resource folder.
As for assembly definitions, when you are already in a large and chaotic project, nothing can help you.
Upgrading and modifying a project is a complex task, especially when the project is already online and operational. I cannot prompt the project to make changes.
Even if Unity provides a better code compilation process in the future, I believe it will still become slow because people do not follow best practices.
I tested this in a large project, and after excluding various art resources, the time from triggering Unity compilation to Unity becoming operable was reduced by about half a minute, which is a significant improvement.
Art resources do not affect Unity’s compilation speed itself, but the compilation will trigger a series of refresh processes in the AssetDatabase. Reducing art assets can shorten the time taken for the refresh process.
Run this through the profiler in edit mode, with deep profiling enabled.
I would not be surprised that ultimately you’ll find one or several editor scripts that will happily run some crappy code like this before or after domain reload:
CreateAsset / ImportAsset
modify asset object
SaveAssets (aka: Save Project!)
AssetDatabase.Refresh()
repeat for every asset, no batching
An AssetDatabase refresh may or may not occur by default during domain reload, I don’t know whether that’s the case. But excluding the art assets folder would necessarily cause the AssetDatabase to be out of sync, meaning the editor would be working with stale asset references. That’s not a solution.
You could check if a) some of the Assets can be removed (may be unused) or b) see if some particular asset(s) are particularly resource intensive and may need optimization.
The use of the Accelerator in a team is also recommended, provided everyone works in the same LAN (Gigabit speeds) and you can run the Accelerator on a server with a fast SSD.
I have previously conducted similar analyses and have locally removed some InitializeOnLoad methods that were not useful to me, which has somewhat improved the Editor’s responsiveness.
I am not a beginner and have always tried to adhere to best practices.
However, the problem remains as mentioned earlier: in a large project with many modules and many people involved, I cannot ensure that every module and every person follows best practices.
When the project has already become problematic, an ignore list is the quickest way to solve the immediate issue, while driving project changes requires a long process.
I doubt Unity will investigate this avenue in the short or long term. The idea is simple, but there’s probably a lot of places that expect assets to be loaded. So it’s not just about adding an option to skip loading a subset of assets in a project, it’s about finding and fixing all the places that subsequently break.
And Unity is already invested in other approaches to alleviate the slowness in big projects: One is the switch to CoreCLR and with it from domain to partial code reload. This should improve the time it takes after code was (re-)compiled. Another is a switch to on-demand async asset importing, which should greatly reduce the time spent waiting for the editor to import changes.
However, both of these are scheduled for a release after Unity 6, so it will take a good while until these will benefit production projects. In the meantime, as CodeSmile outlined, all we can do is the grunt work of optimizing existing projects and making sure they don’t degrade.
I completely agree with your views.
I am merely offering a suggestion that might make Unity more user-friendly in the future, and I do not expect it to solve my immediate problems.