Search Unity

Feedback (Case 1161371) 2019.3: Compiling empty project takes significantly longer

Discussion in '2019.3 Beta' started by Peter77, Jun 9, 2019.

  1. Peter77

    Peter77

    Joined:
    Jun 12, 2013
    Posts:
    4,017
    Compiling C# files in an otherwise empty project takes about 3 times longer in Unity 2019.3 than in Unity 4.6. Please see the provided videos.



    Reproduce
    • Create new project
    • 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.
     
  2. Peter77

    Peter77

    Joined:
    Jun 12, 2013
    Posts:
    4,017
    QA replied, unfortunately not really what I was looking for:
     
    ROBYER1, Chaz32621 and Prodigga like this.
  3. Pyromuffin

    Pyromuffin

    Joined:
    Aug 5, 2012
    Posts:
    71
    I have noticed compile times have taken a hit with this release. Didn't @Joachim_Ante say they wanted to get iteration time under 500 ms? This attitude toward performance regressions is frankly unacceptable.
     
    ROBYER1 likes this.
  4. Peter77

    Peter77

    Joined:
    Jun 12, 2013
    Posts:
    4,017
    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?

    Is this how it works?
     
  5. pointcache

    pointcache

    Joined:
    Sep 22, 2012
    Posts:
    525
    500 ms compilation. :D
     
  6. HaraldNielsen

    HaraldNielsen

    Unity Technologies

    Joined:
    Jun 8, 2016
    Posts:
    38
    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.
     
    ROBYER1, Griz and Peter77 like this.
  7. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    5,824
    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.
     
  8. AlkisFortuneFish

    AlkisFortuneFish

    Joined:
    Apr 26, 2013
    Posts:
    638
    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.
     
  9. ROBYER1

    ROBYER1

    Joined:
    Oct 9, 2015
    Posts:
    282
    Gotta love performance regressions :/
     
  10. DGordon

    DGordon

    Joined:
    Dec 8, 2013
    Posts:
    408
    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.
     
  11. willemsenzo

    willemsenzo

    Joined:
    Nov 15, 2012
    Posts:
    531
    Is there any news on this for future releases? It takes me more than a minute to compile something that usually took me about 10 seconds.
     
  12. AlkisFortuneFish

    AlkisFortuneFish

    Joined:
    Apr 26, 2013
    Posts:
    638
    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...
     
  13. willemsenzo

    willemsenzo

    Joined:
    Nov 15, 2012
    Posts:
    531
    Haven't done that but even in an empty project with a single very simple script it takes much longer than in previous Unity versions.
     
  14. AlkisFortuneFish

    AlkisFortuneFish

    Joined:
    Apr 26, 2013
    Posts:
    638
    I’d still do it.