Are we still working on <500ms Assembly Reload?

After the availability of "Enter Play Mode without Domain Reload", the only thing that stands in the way of our editor iteration speed is the Assembly Reloading time (pretty much the bulk of time it takes to build after you change a script, in addition to the relatively shorter compilation time).

There was a big push on the 500ms goal in 2018 as part of Performance by Default for the Editor. But not too much discussion on it in 2019 (certainly not at Unite). So is Unity still actively working on reducing the build time after a script change? Or are we looking at the problem another way now (via Live Link)?

 

I seen efforts on that mark

https://blogs.unity3d.com/2019/09/11/speed-up-your-team-with-the-unity-accelerator/

 

@Joachim_Ante almost a year later, has there been any updates since last year?

 

any update?

 

Any update? In my medium size project, it takes 10+ seconds to reload assembles… after *every* single change. It really hurts productivity.

 

@aromana Have you seen this? https://forum.unity.com/threads/protip-super-fast-enter-playmode-times-when-working-in-dots.984543/

 

Yes, and that's definitely very helpful, but it only solves the problem for entering/exiting play mode. A great deal of iteration time is also spent editing scripts and returning to the editor, which still takes 10+ seconds.

When that happens, Unity spends a second or two actually recompiling my code, and 3-5x that time (sometimes 10+ seconds) reloading assemblies. That part is still very slow and really hurts my productivity.

 

Indeed. Even if you have all your code neatly split up in assemblies, the domain reload time still increases with the project size. This is why I often have to develop my small tools/features in new empty projects, and then move them back in our real big project. Let's just say it's far from ideal

 

I also get a strange issue with visual studio where, depending on the type of changes made (e.g. Renaming or moving files), all open vs tabs get closed when unity recompiles and reloads. Add this to the wait times and returning to the editor after making code changes is a terrible experience. And we're stuck on 2020.el3 for the rest of the year apparently haha.

 

2021 is not any better.

I find asmdfs just pointless, as editor reloadings, is killing any potential advantages, which these may bring. Forcing to work on smaller chunks of separate project anyway.

 

How do you come up with such a statement? Test the same project side by side. 2021 will win in every metric, not just code reloading.

 

Because I ported our team mid size project to 2021. And before everyone moved, I was still switching occasionally between 2020 and 2021 branches. Pretty much good comparison.
Compilation and editor update times are pretty much the same.
Wait for update popups all over the place. Reload UI, assembly reload, locking editor, etc, etc.
The bigger improvement change for me was between 2019 and 2020.

Even on small prototypes, feels pretty much the same as 2020.
5-10 sec waiting time, for single script line change, and forcing reloading halve of unity editor with its ui update popups, and what's more.

Disabling auto reload is god sent.

We had in past thread somwhere, which was tracking regression performance between Unity versions, past few years. Unfortunately, from 2021 is no more updated into the list, as far I am aware. Based on that test, trending was pretty much one directional.

 

I'm playing with 2021.2 alpha currently. It's so good that I will be crying when I have to go back to the 2021.1 continue the real work. They are moving to the right direction.

(Disclaimer, I always have the domain reload option thingy checked and I only start projects with strict assembly definitions)

 

I thought I was the only one. I actually have several Unity-projects only to test out certain kinds of functionalities for my project because I absolutely hate having to wait. Yet, people will insiste to hate on Javascript in comparison, but at least when I work with it everything's always instant and I can rapidly iterate.

 

It is apples and oranges. The used language has nothing to do with the method of reloading. Zilch, nada.

Besides Unity's Mono is just slow when you reload the domain, javascript is always.

 

Then why is it that every C#/.NET-project I have worked on even outside of Unity has always needed a bit longer compile time before I can see the changes I did? Even a simple console application in C# has taken me a few seconds to compile before I can try it.

 

I didn't say there is no compile time. I said it is apples and oranges. Javascript is usually an interpreted language, so it is always slow. C# is a compiled language. You're trading build time on development for more performance at the end user.

I guess you haven't seen C++ lately...
C# even with our current Mono and all the domain reload is a very good middle of the road when it comes to "build".

 

Found this on the 2021.2 subforum https://forum.unity.com/threads/any...pt-assembly-reload-time.1117138/#post-7200076