Search Unity

  1. How has 2019.2 and the beta been for you so far? Give us feedback in this thread.
    Dismiss Notice
  2. We would like to hear your feedback about Unity and our products. Click here for more information.
    Dismiss Notice

How about "Performance by Default" for Editor

Discussion in 'Editor Workflows' started by chrisk, Dec 19, 2018.

  1. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    440
    My project keeps growing and it takes about 25 seconds to go into "Play" mode. It will soon reach half-a-minute soon. We barely began the project.

    It's was very painful and now it's unbearable. I'm going to upgrade my PC once again if it can save few seconds. I think it worths it.

    I'm really that desperate for better productivity. 3 seconds * 1000 times a day is about 50 mins and it can save about a couple days a month.

    Unity! Please do something about it!

    I know it's doable once you set your mind to it.
     
  2. 5argon

    5argon

    Joined:
    Jun 10, 2013
    Posts:
    1,231
    It looks like you have doubt that they don't have any intention to fix this issue, until you get a response in this thread? In that case is this suffice for you : https://forum.unity.com/threads/unity-incremental-c-compiler-deprecated.523993/page-9#post-3987316 also it indicates that they know full well about this. One other thread I can't find, Joachim talk about there're so much more he can do about "hot reload". I imagine a big rework is underway to truly not compile everything in more granular level than .asmdef.

    Also I got one tips, if you are a debug-logger and not using editor attaching you can turn that off in the Preference. It can save some play mode entering time currently. I am at ~10 seconds but with that on it is usually 12-15 seconds.

    One more tip, a big one that immensely help me I recently practiced doing. You should utilize local UPM. Compose your project from multiple local UPMs instead. Because the time to enter play mode depends on number of scripts in the project and not things in the scene, if you develop each UPM module in a separate project then combine together later you will get fast iteration time when working in each module in their own project. Why do you enter play mode and suffer 30 seconds wait? To test things. If you do local UPM, then there are less things to iterate test in the big project and save you big time on the weakness of Unity.

    Make sure a test assembly is contained in each module. That way Play Mode Test will not be so gatekeeped by play mode entering time. It is the best way to fight with this problem right now, in a way that will also benefit your game and your other game in the future when you can reuse your own packages.

    But it is much better if you could do everything in Edit Mode Test to avoid big play mode entering time altogether, with `yield return null` support you can even do network test in edit mode. I made a library which use Firebase Cloud Firestore from Unity with REST API, it works in Edit Mode Test and I could wait for results, all separated from my full game before I plug it in. (Then I need some integration test to bridge the two, but mostly those faster isolated project unit tests already took care of)
     
    Last edited: Feb 7, 2019
  3. Xblade-Imperium42

    Xblade-Imperium42

    Joined:
    Jan 12, 2016
    Posts:
    605
    Yea, it takes a stupid amount of time. No idea why it recompiles every asset in the entire project for every small change, either.
     
  4. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,276
    Assembly reload time, mostly. As Unity projects scale you find Unity doesn't scale at all, so you will need to handle it manually in some manner or other, and usually this involves figuring out how to avoid Unity reloading the entire planet.
     
    Xblade-Imperium42 and SugoiDev like this.
  5. Xblade-Imperium42

    Xblade-Imperium42

    Joined:
    Jan 12, 2016
    Posts:
    605
    Have any tips? I used the "Maintainer" Unity asset to separate unused src will dramatically helped, but my Assets dir is still pretty large. I also suspect that my cache wasn't cleared for the files I separated from src, bloating my SSD. As for handling it manually beyond this... I wouldn't know where to start.
     
  6. neshius108

    neshius108

    Joined:
    Nov 19, 2015
    Posts:
    68
    @
    Please @hippocoder, tell us how to do just that!
     
  7. dadude123

    dadude123

    Joined:
    Feb 26, 2014
    Posts:
    785
    Just to throw a few things in here:
    - For me entering/leaving play mode in an empty project (trying both 2018.2 and 2019.1) takes approx 0.2sec. So its really fast
    - My personal project is split into multiple components (multiple unity projects). I load the assemblies and unity content at runtime in the "main game project". That allows me to work on many things separately, every single project is very fast. Stuff like levels/environments are in the "main game". UI is its own project (which is pretty big!). Then there's another project for various "assets" that mostly has some scripts to create asset bundles that the other projects use.

    But I definitely agree on the greater point of this thread (just not the issue with the reloading, that's just your own fault for using addons that take a long time to do their stuff. Should just be better optimized I guess. But then again I barely use any addons / external assets from the store).

    If we ignore the huge load times for a moment, the biggest issue that shows that Unity is only for (very) small projects is that the asset browser/explorer simply has no folders.

    Like, view an UGUI image component in the Inspector. Click the little dot that allows you to select a sprite/image for it, that browser window thing that opens is the one I'm talking about. How can it be that this thing can't filter by folder or tags or something???

    However, in the end every engine has its downsides. There will always be people who can deal with it, make it work somehow, and others who'll get stuck. UE4 does *many* things better than Unity, yes, but it also has its disadvantages.
     
  8. neshius108

    neshius108

    Joined:
    Nov 19, 2015
    Posts:
    68
    @dadude123, your setup works for you but that clearly doesn't work for everyone.

    The point is that we want to find ways to improve our productivity without having to switch engine whenever we find something annoying that could be better.
     
  9. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,276
    There's nothing I can suggest other than throwing your scripts that will not change into a Plugins folder or dealing with the whole assembly dance, which is actually a proper pain in the arse, but it is what it is.
     
  10. dadude123

    dadude123

    Joined:
    Feb 26, 2014
    Posts:
    785
    Yeah thats true. I didn't intend to say everyone should do it as I do.

    Unity has a ton of stuff to improve in this aspect.
    Usability with large projects. Reload times. ...
     
  11. neshius108

    neshius108

    Joined:
    Nov 19, 2015
    Posts:
    68
    @hippocoder

    here is my current headache:

    upload_2019-5-7_0-0-50.png

    Compile times are acceptable but `Assembly Reload Time` basically made all my half-day refactoring into Plugins/StandardAssets + asmdefs utterly useless.

    I would love to be able to force unity not to reload assemblies which have not been touched (otherwise what's the point of asmdefs if it still takes ages?)

    Any hint?
     
  12. dadude123

    dadude123

    Joined:
    Feb 26, 2014
    Posts:
    785
    Yeah, at least there are *some* things we can do to mitigate the problem for the most part.

    But people should not forget why it is that way. I'm not sure if everyone in this thread is really fully aware of the technical details here.

    One can view the situation like this: these issues are actually (in a way) a price we are paying.
    But what do we pay for? What are we getting?

    We're getting .NET/C# and all its countless and massive advantages.
    And with that comes the price of the runtime (in our case: Mono).

    If I had to chose between having dotnet + these problems, or having a system like UE has (Blueprints + C++), I'd pick the Unity approach every single time, with absolutely zero hesitation.

    I'm not trying to say the problems reported here are invalid or anything. Just trying to explain why we're having them.
    Unity should definitely do better here.
    But I think it's actually not even all that easy to do. The full switch to .net4.x / net standard 2.0 was not too long ago, and the changes and consequences are still propagating through the Unity ecosystem.

    Again, not sure how informed everyone in here is, but the "performance by default" thing for the editor will come - in fact it's definitely being worked on. One of the recent videos has shown that some real nice improvements for this are on the roadmap already. Even some insane stuff like not even having to reload the appdomain to enter play mode! If that will end up actually working, It would be literally "instant play" as you guys want it!
     
    hippocoder likes this.
  13. neshius108

    neshius108

    Joined:
    Nov 19, 2015
    Posts:
    68
    @dadude123, you being apologetic helps absolutely 0. If this is not an issue for you move on and enjoy your Unity experience. If wasting tons of time for basically nothing is something you are not happy with then discuss it with others and try to find a solution or try to get the Unity peeps to look into it.
     
  14. dadude123

    dadude123

    Joined:
    Feb 26, 2014
    Posts:
    785
    I know you're asking hippocoder.
    But I feel like I can give an answer as well:
    Unfortunately there is no way. Reloading the appdomain (which will always reload *every* assembly) is a very important thing to do. At this moment there's not really much you can do.

    If your current scene is large (has many c# components) then that is an important factor as well.
    You can try to see if the appdomain reload takes the same time with an empty scene open.
    The domain reload itself should definitely not take 7sec.
    So my guess is that there are many scripts in your scene that have to be serialized, thrown out, then deserialized after the new assemblies are loaded.
     
    hippocoder likes this.
  15. neshius108

    neshius108

    Joined:
    Nov 19, 2015
    Posts:
    68
    @dadude123, the only thing I am aware of is the heavy use of `[SerializeField]` and I have a couple of assets from the store.
    I would looooove to be able to pin point what is causing the slowdown. Any tip? The profiler doesn't seem to tell much sadly.
     
  16. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,276
    Yeah although the idea of instant play will probably never happen in the monobehaviour world. Unity is probably going to only work with that for DOTS. So if your project is not DOTS-based and you're not using a 2020.1+ version then I do not expect compilation or reload time to change.

    The reason for this is the whole assembly reload thing. I don't think it's actually a thing Unity will fix for mono editor projects.

    This is just my own observation and I haven't received any information from Unity in this regard, I just think it's logical that Unity is looking at solving this the right way, which means "build a better solution".
     
  17. neshius108

    neshius108

    Joined:
    Nov 19, 2015
    Posts:
    68
    For future readers, after lots of tests, here is what I did to manage to go from 9-10s to 6-7s in the compile/reload times:

    1. Moved imported assets and general tools into the "Standard Assets" folder (name has to be that)
    2. Removed as many files as possible (I went through and deleted all the Docs/Example/Demo folders from the assets I was using), their size is not necessarily important
    3. Removed default packages which I didn't need: Ads, IAP, Analytics, Multiplayer, XR Legacy, Memory Profiler (you can always bring them back whenever you actually need them)

    Notes: if, for some crazy reason, someone doesn't use the attach debugger feature in VS-Unity, disabling the "Editor Attaching" from the preferences, actually makes the reloading quicker (about 0.3-0.5s for me).

    Other crazy stuff I found:

    Unity seems to spam registry calls for certain player prefs, if they are not found, it will still try and try and try. Using process monitor, you can actually find the key and create an empty one in the registry. Little bit of a hack but worked and it stopped wasting time there.

    As a side note: it turns out Unity loads the verdana(b) fonts every single compilation, it only takes 0.003s but yeah it adds up :p

    And now, I can finally go back to develop in peace :rolleyes:

    EDIT: Posted a little tutorial/post about the adventure: https://gamejolt.com/games/talesofk...attempting-to-decrease-compile-times-she9y7qf
     

    Attached Files:

    Last edited: May 8, 2019
  18. Roni92pl

    Roni92pl

    Joined:
    Jun 2, 2015
    Posts:
    261
    +1 on assembly reload times, and also generally handling game objects and components could be much faster.
    I mean duplicating or moving hundreds of GOs takes it sweet time when there are lot of them.