Right-click in Project window and chose “Create C# Script”
Observe gears icon in lower right corner as indication when Unity is done
Repeat these steps with Unity 4.6 and Unity 2019.3
Actual
Creating and Deleting, probably recompiling in general, C# source files in Unity 2019.3 is significantly slower than in previous Unity releases.
In my test:
Unity 4.6 = 2 seconds
Unity 2019.3 = 6 seconds
Expected
Newer Unity versions should not be slower than older ones.
Note
Please use hardware similar to the PC I used to submit the bug-report with. It probably can’t be reproduced on high-end machines.
I have noticed compile times have taken a hit with this release. Didn’t @Joachim_Ante_1 say they wanted to get iteration time under 500 ms? This attitude toward performance regressions is frankly unacceptable.
Today I received another email from QA. It seems they looked another time at this issue, here is the reply:
I’ve observed packages often use Assembly Definition Files. I hoped if code is compiled via asmdef to a separate assembly, it would not affect unrelated code to reload, but it seems that’s not true?!
In this case, the more packages I’ve added to the project, the longer every “recompile” takes. Where it does not necessarily have to be the actual recompile, but the JIT and reloading of every single assembly in the project, even assemblies that don’t have a dependency to the code that changed?
Hi guys, trying to shed some light on how things work
Packages are enforced to use asmdef’s, so the package’s code do not get included into user compiled assemblies and by result should minimize the compile time when the packages are already compiled.
During a domain reload, JIT is only a cost when the code is executed, but if packages is using InitializeOnLoad, or other’s that are invoked after a reload, and they are doing something time consuming, it will slow down the whole flow, and will do so even if you are referencing the package or not in your own asmdef.
We are working on some tooling that will help Users understand what is happening, and what is taking up time under compilations/domain reloads.
Tooling will not help if we can’t do anything about it, it will only help us make more pointed complaints.
In the meantime, can you turn TextMeshPro back into an asset? I would then potentially be able to get rid of the package manager, it has only brought problems it seems. The collaborate team spent so much time turning collab into a package they forgot it is also supposed to function.
TBF, you can just import many packages, including TMP, into your project, delete the assembly definition, and remove them from the package manager if you want. Not sure what you’d gain, but you can do it.
I’m very unclear if splitting our project into different .asdef files (engine, editor, game data) is actually something that should theoretically make a noticeable difference, or if there’s still enough other cruft going on that even if we got rid of the actual “compile” time, it still wouldn’t make a big difference.
Our project is really split into three areas: the engine, editor, and game data (.cs files generated by editors). In theory it sounds like it should be split into different .asdef files … but I’m having a hard time telling if its worth refactoring at this point for a speed boost.
Would putting all the “engine” files into its own .asdef, which does not call InitializeOnLoad, cause their time to essentially be zero when a recompile happens because of game data, or is it going to be something like 80% because there’s other factors involved I dont know about?
Does having InitializeOnLoad in editor files mean we incur zero compile time, but we still incur the time of however long it takes for my InitializeOnLoad code to run (which should be obvious)? Or are you saying that InitializeOnLoad will also cause other things (ie: the JIT cost) to kick in … and if so … what does that actually mean? Should I still expect that having all editor files in an .asdef even with InitializeOnLoad will cut the time by a large percentage compared to not having it in an .asdef, or does .asdef vs no .asdef become much more comparable once InitializeOnLoad is factored in?
Basically … it would be great if I could change a data.cs file, and ONLY have the data .asdef do whatever it needs to during recompile. But I’m not sure if that’s what .asdef actually accomplishes.
Over a minute doesn’t sound right at all. Have you profiled it with Profile Editor to see where the time is actually spent? Sometimes you can be (un)pleasantly surprised…
Tested Unity 2019.3.0f1. It’s still the same as I described in the first post. 2019.3.0f1 takes roughly 6s, which is about 3 times slower than Unity 4.6.
For what it is worth from my limited experience probably one wants to go fully asmdef, or fully not. Having both mixed in a project increases compilation time as a kind of “catch all” asmdef is built in this scenario for the code not think. already in asmdef. Given the package manager is the preferred way to get a bunch of very useful standard features e.g. Post processing, textmesh etc then asmdef is probably more and more important for larger projects. Disclaimer: don’t take my word for it.
Sorry for getting back so late, yes the tooling with help with two things:
To see if you as a user is doing something in your project that takes a long time. Today using the profiler can be going trough a big haystack if you just want to see why iteration time is slow.
If you know what is slow, maybe you can take actions to be able to fix it.
To make much more informative bug cases, the more we know up front the faster the correct team will get it and be able to fix it.
“Would putting all the “engine” files into its own .asdef, which does not call InitializeOnLoad, cause their time to essentially be zero when a recompile happens because of game data, or is it going to be something like 80% because there’s other factors involved I dont know about?”
Putting code into asmdef’s will only help on compile time. Given you have only have to compile what has changed.
But InitializeOnLoad is called everywhere, every time.
The reason is that a domain reload is basically shutting down the .NET runtime, and restarting it (to some extend), so everything needs to be reinitialized. So if some package, or your code contains InitializeOnLoad that is slow, it will hurt domain reloads.
“Does having InitializeOnLoad in editor files mean we incur zero compile time, but we still incur the time of however long it takes for my InitializeOnLoad code to run (which should be obvious)? Or are you saying that InitializeOnLoad will also cause other things (ie: the JIT cost) to kick in … and if so … what does that actually mean? Should I still expect that having all editor files in an .asdef even with InitializeOnLoad will cut the time by a large percentage compared to not having it in an .asdef, or does .asdef vs no .asdef become much more comparable once InitializeOnLoad is factored in?”
Yes. Fx when opening a project that is already compiled, will still need to start the domain, will also call all InitializeOnLoad’s.
Even if compile time would be instant, InitializeOnLoad would still have a cost.
After I updated the bug-report, QA replied with the following text. Thanks for the speedy reply!
… which is basically the same response I received earlier .
I’m really questioning my effort to have reported all these regressions, as it seems none of these issues is important enough for Unity Technologies to fix.
this is reason why i so angry to unity 2019.3’s Technologies now,
this version is the most slow & lag before any version
no matter what i do, any thing!!!
don’t ask me what i do, because the every thing is so slowly
when i click the editor
when i create new script
when i change the script
when i enter or exit platMode
when i built the apk
when i open the editor
when i select the gameobject
can you believe? everything is lag and slow
i report dozens of feedback emails, 99% the QA tell me they can not reproduce it & close
I know it is not much, but I would like to add my voice to the crowd that is asking for more performance in editor.
Nothing Unity did since I started using it in 3.x is more important than speedy editor for fast iterations.
Keep up the good fight, @Peter77
There are dozens of us right now.
I know there are many more lurking that have yet to get their voices here. I hope more will come out soon. In particular the more experienced developers that had to deal with this death-by-a-thousand-cuts daily in larger projects.
I hope to see any editor performance regression being treated as high priority bugs instead of “by design”.
My operating system does an insane amount more than Unity, and it boots faster than Unity can recompile + reload its assemblies.
Is it me or that should not be the norm?
Good quality gameplay design depends a lot on fast iterations for tweaks. I’m loving the assembly reload-less playmode entering, but I think we can do better.
Edit: I would like to add that I know that Unity is putting more effort in Editor performance and this message is just to express support for their efforts. In particular, I know several key areas are now being monitored for performance and analytics is being gathered.
There’s even some effort for a .NET Core port for the editor (imagine that!).
I really think this time we’ll have something, so I think it’s worth that we try and voice our opinion now to show us, the developers using this tool, support this effort.
