Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.

Official Improving iteration time on C# script changes

Discussion in 'Scripting' started by xoofx, Oct 18, 2021.

  1. fetish

    fetish

    Joined:
    Aug 25, 2015
    Posts:
    73
    I'm on 2021.2.1f1 as well and the issue is TERRIBLE. I'm getting 30 second reloads even on brand new, empty projects, out of the box. It also takes 5-10 minutes to simply open a project, even a new one.

    While I am using a somewhat older machine, I was dealing with very brief (2-5s) reloads around 2019 or so. I have even reinstalled my operating system (Win 10) fresh within the past year and the issue with Unity persists.
     
  2. giraffe1

    giraffe1

    Joined:
    Nov 1, 2014
    Posts:
    281
    Yes, I noticed this too. The load times in 2021 are really bad.
     
    erdostamasa likes this.
  3. EagleG

    EagleG

    Joined:
    Mar 17, 2018
    Posts:
    401
  4. ssyuha

    ssyuha

    Joined:
    Oct 6, 2021
    Posts:
    9
    Or maybe can give the new Unity 2022 Beta a try. Now if we disable Auto Refresh, it will reload asset when Enter Playmode after changing script. In older version we need to refresh manually if Auto Refresh option is disabled.
     
  5. richardzzzarnold

    richardzzzarnold

    Joined:
    Aug 2, 2012
    Posts:
    137
    ***If your project is sufficiently large (based on number of scripts, number of assets stored in asset database) ... none of the steps proposed across the five pages of this thread, and 20+ pages of other threads, will achieve editor iteration below 5 seconds. Having literally worked through every optimization proposed here I have no remedy beyond Unity fixing the severe regression in iteration performance. @xoofx***



    A year ago iteration was instantaneous.
    Now that it has been "improved", every possible action requires lengthy waiting times.
    Shifting responsibility to the developer/user to completely rebuild every aspect of their project including all plugins , seems , well, a bit weak.
    Maybe instead of spending a billion dollars to buy Weta Digital, Unity could just focus on getting their software to work?
    Just sayin'
     
    Last edited: Apr 18, 2022
    akuno, TigerHix, erdostamasa and 3 others like this.
  6. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    372
    Thank you Unity for your continued efforts. Six months has passed since this thread was created -- do you have an official update you can share? *edit to @Maria_Angelova

    Thanks
     
  7. Sjonsson

    Sjonsson

    Joined:
    Nov 28, 2016
    Posts:
    6
    +1

    Felt like liking your post wasn't enough so here's a bump: BUMP!
     
    DavidJares, erdostamasa and kloot like this.
  8. Cicaeda

    Cicaeda

    Joined:
    Sep 29, 2017
    Posts:
    26
    helo plz fix
     
  9. DragonCoder

    DragonCoder

    Joined:
    Jul 3, 2015
    Posts:
    578
    Cases like those really have something todo with the particular machine...
    I cannot even by far reproduce that on my 3 years old ultrabook mit mobile U-CPU.
     
  10. simon-ferquel-unity

    simon-ferquel-unity

    Unity Technologies

    Joined:
    Apr 1, 2021
    Posts:
    29
    Hi,
    There is an optional diagnostic switch you can enable (which has a small overhead, so it is not enabled by default) helping diagnosing domain reload issues (see my post here: Any update regarding "Increased script assembly reload time"? - Unity Forum).
    This will give you much more details about what is going on, and can give you insights about the sources of those big slowdowns.
     
    Lahcene likes this.
  11. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    372
    @simon-ferquel-unity Who is this reply addressed to? Is the performance team and @xoofx still actively working this critical issue? In other words, no one is waiting for telemetry to get this fixed?
     
  12. simon-ferquel-unity

    simon-ferquel-unity

    Unity Technologies

    Joined:
    Apr 1, 2021
    Posts:
    29
    This is adressed to anyone experiencing domain reload issue. There is unfortunately no silver bullet to fix this category of issue. Users can use the diagnostic switch to get better understanding about which component is the source of the problem (a particular UI window taking a long time to reload? Some extension timing out on a blocking web api call?...).
    You can also send the editor logs produced with this switch enabled in a support ticket to get help from our teams.
     
    Lahcene and DragonCoder like this.
  13. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    372
    Simon, I find your post very distressing. I am going to reply back tomorrow in full. In the interim, if you haven't already please read this thread from the beginning.
     
    wbourchier likes this.
  14. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 20, 2015
    Posts:
    8,726
    Something is wrong with your hearing then, because I hear:

    "Check what's happening, run the diagnostics, if something is fixable by you, do it, if not, send the data with the bug report".
     
  15. RobertOne

    RobertOne

    Joined:
    Feb 5, 2014
    Posts:
    183
  16. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 20, 2015
    Posts:
    8,726
    Look, since I don't have access to your bug report (naturally), I have no idea what was truly shared during the submit, but judged based on the available text it is just "look, it's slow, do something". Which is a known issue and Unity stated multiple times that there are things they can do and they are doing it, some things need more time since they need to refactor many things and there are things where they don't know if they can do something because it's simply not happening when and on computers they are trying.
    If you read back this thread, there are some tools you can gain more data with, what's happening during importing assets and compiling code, if you run those and get some more information, submit it to Unity so they can identify the problems and they can fix it.
    Otherwise, they're working on it with other people who actually can share more details about the problem

    If you actually have done that and still got closed, ask for a reopen. Human mistake can happen any time and bugs can get closed without a good reason sometimes.
     
    RobertOne likes this.
  17. Der_Kevin

    Der_Kevin

    Joined:
    Jan 2, 2013
    Posts:
    516
    if you start your unity 2021 project with the -noUpm command from the windows commandline, your compile times get a lot better.
    Without -noUpm ive got 1 second + more (2.5 sec). turning off the "windows real time protection" speeds that up again by 100ms

    -noUmp disables the package manager btw, so be aware!
    https://docs.unity3d.com/Manual/EditorCommandLineArguments.html



    for comparison, these are my ususal compile times i am having with Unity 2021.3.0f1 the package manager enabled and windows defender on. With 1 Single Script in the project and only the latest visual studio package, default render pipeline:
    upload_2022-4-22_8-3-22.png

    at the 7 second compilation mark, i also had the infamouse (hold on, reload script assemblies) bar.

    in unity 2020 the compile times with both off (-noUpm & no realtime protection), are exactly like in 2021 with both off. 1.3seconds. with both on it wil go a bit over the 2 second mark, so less then what you see in 2021 with both on

    in unity 2019 this trick doesent have much of an impact.its 1.4 seconds with both on, and 1.2 seconds with both off

    so my observation is:
    the package manager
     
    Last edited: Apr 22, 2022
    Lahcene, KYL3R, kloot and 5 others like this.
  18. simon-ferquel-unity

    simon-ferquel-unity

    Unity Technologies

    Joined:
    Apr 1, 2021
    Posts:
    29
    @Der_Kevin thanks for this observation. I'll raise the issue to the package manager team.
     
    erdostamasa, Lahcene and RobertOne like this.
  19. Adrian

    Adrian

    Joined:
    Apr 5, 2008
    Posts:
    773
    One of the major contributing factors to increased domain reload times is the move of more native engine code into managed code in packages. Back in the old Unity days, almost the whole engine was implemented in the native side and only the code in Assets needed to be reloaded. Nowadays, big parts of the rendering stack, input system, UI and other engine components are managed code and contribute to the domain reload time. The amount of managed code in an "empty" Unity project has probably increased by more than an order of magnitude.

    -noUpm
    is the same as removing all packages. In today's Unity, that means removing half of the engine and that significantly reduces reload times.

    And I wouldn't want to go back to an all-native Unity. Being able to update parts of Unity separately, releasing experimental packages earlier, making more of Unity's source available for inspection and editing, or having third-party code in packages instead of in your Assets folder – those are all great improvements that and I don't want to give up.

    But this means domain reload times are a trade-off, not an issue with a singular fix. They'll likely never be as quick as they were in old Unity versions. Maybe, with .Net 6+ and a new way of doing domain reloads that Unity is planning together with Microsoft, will we see a general improvement – but that's likely a few years off.

    I do want Unity to try their utmost to keep domain reload times down and to find, fix and proactively prevent issues in packages that exacerbate them. But I don't expect any dramatic general improvements anytime soon.
     
    TigerHix, Lahcene, Luxxuor and 2 others like this.
  20. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    9,547
    The thing that blows my mind, is that this more or less proves that assembly definitions (an advice that is being thrown around a lot, in this thread even) doesn't really work, because otherwise, surely packages wouldn't have such a big impact.

    So the short answer is: There is nothing you can do. It's a design decision Unity made. Editor iteration and performance just suck now, just deal with it. Everything Unity is suggesting is a misdirection and passing the blame to the users, while from year to year, these things keep getting worse.

    It is what it is. Just keep it in mind when you start your next game.
     
    TigerHix, Lahcene and kloot like this.
  21. DragonCoder

    DragonCoder

    Joined:
    Jul 3, 2015
    Posts:
    578
    It does not remove packages that are already loaded in the project though, right?
    Like it won't break a URP project for example which you could only set up if having the package manager in the first place.

    Your explanation is interesting in every case and sounds plausible. Would explain why the dev team can improve small things like what they say to do in 2022 releases, but cannot return to the performance Unity once had in this regard.
    It's an unfortunate but perhaps needed trade. Packages are adding nice flexibility and especially editability. I modified the Animation 2D package for example and that would be impossible if it were native.

    A few seconds of wait time is fair for that. I usually have unity on another screen. So I code, save, click into the window to trigger reloading and then keep coding or thinking about the code until the reload finishes.
    It also forces you to expose settings early in the inspector which is not inherently bad because having constants in code is a bad thing too.
    People who have literally multiple minutes of load times should really follow the advice to use the special profiler and post the details/logs. Am not sure I've seen anyone showing that so far.
     
    Last edited: Apr 22, 2022
  22. Der_Kevin

    Der_Kevin

    Joined:
    Jan 2, 2013
    Posts:
    516
    gotta disagree. the long compile times i shared above are the same even without any package in the project.
    -noUpm is only giving the speedboost
     
  23. Adrian

    Adrian

    Joined:
    Apr 5, 2008
    Posts:
    773
    Assembly definitions are good for bringing down compile times. Only assemblies with changed files and its dependent assemblies have to be recompiled. But compilation nowadays is pretty quick, the domain reload is taking most of the time and the it always needs to reload everything, splitting stuff into assemblies doesn't help there at all.

    But I still expect Unity to improve reload times and think there's definitely opportunity to do so. They're just small improvements spread over many packages and will be slow to address. I don't expect dramatic improvements but I do expect incremental and continued improvement to reload times.

    I believe it does? If you start Unity with
    -noUpm
    , there will be no packages in the Project window and script referencing any packages will create a compile error.

    A quick test from me on Unity 2021.3.0 using the domain reload timings:
    Code (CSharp):
    1.                      Upm       -noUpm    Change
    2. Without packages:    0.646s    0.653s    0.007s (1 C# file and 0 packages)
    3. URP template:        1.297s    0.654s   -0.643s (4'768 C# files and 50 packages)
    4. Current project:     4.305s    error            (5'933 C# files and 67 packages)
    I don't see a change without packages but a 50% decrease with the basic URP template project.

    I hope Unity can address the slowdowns you see with UPM but I don't think it's the root cause of the issue discussed here.
     
    Last edited: Apr 22, 2022
    kayroice and DragonCoder like this.
  24. Der_Kevin

    Der_Kevin

    Joined:
    Jan 2, 2013
    Posts:
    516
    interesting. whats your CPU?
     
  25. Adrian

    Adrian

    Joined:
    Apr 5, 2008
    Posts:
    773
    Edited the post above with project stats. This is total files in project folder (including
    Library/PackageCache
    ), as well as packages including dependencies (just a count of the folders in the package cache).

    I usually also have a few different tabs open and noticed them appearing in the domain reload timings of my current project. If I switch to the default window layout, it looks like this:
    Code (CSharp):
    1.                      Many Tabs  Default Layout  Change
    2. Current project:     4.305s     3.416s          -0.889s
    Apple M1 Max
     
  26. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    9,547
    Sure, but they are offered as a solution when people complain about editor iteration.
     
    Lahcene and kloot like this.
  27. Trindenberg

    Trindenberg

    Joined:
    Dec 3, 2017
    Posts:
    168
    I wish there was an option for potato mode.
     
    Lahcene likes this.
  28. Der_Kevin

    Der_Kevin

    Joined:
    Jan 2, 2013
    Posts:
    516
    Just a bit of an update. i managed to get compile times under 1 second (2021.3.0) by:
    - noUpm command
    - turning off windows real time protection
    - added the project folder to Excluded Folders in Windows Indexing Service
    - Added same folder to the exclude folder to Windows Antivirus

    upload_2022-4-22_17-14-22.png

    as soon as i am removing the -noUpm command line command, and add a package like visual studio, compile times go up again and the range is also pretty high. but also without any package, the timer is always aroundthe 2 sec line

    upload_2022-4-22_17-22-47.png

    not much more info then the previous but i just wanted to be sure if i get the same result on my other windows pc
     
    akuno, Lahcene, EagleG and 3 others like this.
  29. KYL3R

    KYL3R

    Joined:
    Nov 16, 2012
    Posts:
    110
    There has to be a simple fix for this. I can't forcefully speed it up anymore, I already have a NVME, intel i9 and 32GB RAM. What would Laptop users do?

    I use Assembly Definitions as well, and if I have 4 scripts in one assembly definition, Unity should not take 12+ seconds when I add a Space to my code and hit save.

    Yes, the Engine now has more managed Code and I like the progress Unity is making, Shadergraph has come a long way for example. But there has to be a way to separate Plugins from your game logic...
     
    TigerHix, Lahcene and kloot like this.
  30. Adrian

    Adrian

    Joined:
    Apr 5, 2008
    Posts:
    773
    The domain reload is taking most of the time and Unity has to reload the whole domain, including all loaded assemblies. This is because in Unity, everything can interact with everything else. Even if code is split between assemblies, one assembly can use the code and objects of other assemblies freely. You cannot just reload part of it, you don't know what parts might, directly or indirectly, rely on it.

    Unity could use multiple domains and then reload just the domain the changed script is part of. But that would mean code can no longer directly interact and would have to use a messaging mechanism to communicate, which would e.g. make writing editor code much harder.

    12+ seconds on a modern computer is a lot, what operating system are you on and how big is your project?
     
    akuno likes this.
  31. Gaspedal

    Gaspedal

    Joined:
    Mar 29, 2009
    Posts:
    374
    same here. I'm on Unity 2021.1.22f and need over 5 minutes for my project until the editor opens. And that's on my high-end PC. Very terrible. When I close the editor, and reopen my project, then it's faster (10 Seconds). This only happens when my PC starts for the first time or I don't use Unity for a long time.
     
    Last edited: Apr 23, 2022
  32. DragonCoder

    DragonCoder

    Joined:
    Jul 3, 2015
    Posts:
    578
    Is that an inherent "issue" of C#?
    How comes C++ can just recompile single files and their dependencies to work? o:
     
  33. oscarAbraham

    oscarAbraham

    Joined:
    Jan 7, 2013
    Posts:
    165
    Both C++ and C# don't even need to recompile dependencies if they are separate assemblies. They can even use newer versions of the dependencies if they are compatible without recompiling anything. But compilation is not the issue here.

    Even if compilation was instantaneous, first the previous version of the program must be stopped and its memory must be released, then the new compiled version must be loaded into memory and executed. Also, in order to make it a somewhat seamless experience, the data of the previous program must be serialized before unloading it and then it must be deserialized into the new program.

    That's usually even harder to do with C++. C++ doesn't even do JIT. There are some known solutions to hot reload C++ code very quickly, but they require some very specific conditions, and only support very specific code changes that don't change the current data state.
     
    Lahcene likes this.
  34. DragonCoder

    DragonCoder

    Joined:
    Jul 3, 2015
    Posts:
    578
    I see.. right.. With "in Unity, everything can interact with everything else" Adrian referred to the fact that our custom code must interact with the inspector and all that which makes this approach necessary.
    Makes sense.
     
  35. KYL3R

    KYL3R

    Joined:
    Nov 16, 2012
    Posts:
    110
    I'm on Win10 Pro, Project is 29Gb (including Library Folder). "Assets Folder" is only 9Gb.
    Unity Hub, Unity Installation and the Project are stored on my NVME Disk.

    For some reason, it is faster now. I tried the "-noUpm" mentioned above, but obviously that breaks my project. So I removed the parameter and reopened my project, which did some re-importing (took a few minutes).
    And now the "reload script assemblies" is a lot faster.

    Can somebody (with a long assembly load time) try to delete the Library Folder and see if it's better after Unity re-imported everything? Maybe there is just a lot of garbage piled up?
     
  36. richardzzzarnold

    richardzzzarnold

    Joined:
    Aug 2, 2012
    Posts:
    137
    I have spent more than 12 years developing with Unity and it has come to a point where I really have to seriously consider shutting down as the editor performance has just become impossible to work with.
    I spend about 7 out of every 8 hours now waiting for Unity to compile or reload something.
    It is just not realistic to work with it anymore.
    It's so incredibly frustrating. Any remote prospect of work efficiency has gone totally out the window. My productivity has gone down to about 5% of what it was a year ago.

    Is there actually anyone at Unity that thinks that this is seriously able to be used by any business?
    It's as if none of the Unity dev engineers have ever actually tried using it themselves on any real project.

    I am astonished that any company could release software that performs so abysmally.
     
    Last edited: May 5, 2022
  37. kloot

    kloot

    Joined:
    Mar 14, 2018
    Posts:
    33
    Dear Unity people. Respectfully, its probably a good idea to post an update here on the progress of the mentioned task force that was assigned to sort these issues out.

    As Unity moves closer to.NET (finally ), the domain reload issues will likely go away, but having csproj/Core CLR and Nuget is realistically years away.

    Thanks
     
    Lahcene and richardzzzarnold like this.
  38. hawaiian_lasagne

    hawaiian_lasagne

    Joined:
    May 15, 2013
    Posts:
    102
    Hello!

    I'm using Unity 2021.3.0f1 and was experiencing serious slow down issues until I removed some unused packages, and now it's back to normal again. No more 20s 'reload script assemblies' in my small project.

    These are the packages I removed:

    Visual Scripting
    Rider IDE
    Visual Studio Code Editor

    I also updated Visual Studio Editor to 2.0.15 (I'm using 2022).

    Hopefully this might help someone.
     
    TigerHix, wedgiebee, Lahcene and 2 others like this.
  39. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    372
    I agree with @AcidArrow's sentiment. This issue has persisted for the better part of two years and the professional (full-time, employed, studio) engineers have been very vocal about the impact. Not everyone is affected but the many who are have clearly communicated a need for transparency, communication, and urgency.

    @simon-ferquel-unity's recent post shows us that Unity staff is requesting telemetry to further diagnose a cause. I find this incredulous, as this issue is over two years old and we have discussed the behavior ad nauseum with supporting telemetry.

    With a demonstrated lack of meaningful progress I hypothesize that this outcome is caused by a lack of political and technical will within Unity to fully overcome the issue using current engine architecture. To be clear, resolution of the issue is a full return to sub-second editor iteration time comparable to 2019.x.

    I'm a steadfast fan of Unity and its stated goal of democratizing game dev. But, and this is important -- at the end of a day a product must ship. This issue makes it more difficult to ship products on budget and on schedule and as others have suggested, it requires us to evaluate alternatives.

    I welcome feedback from the Unity team demonstrating meaningful progress!
     
  40. xoofx

    xoofx

    Unity Technologies

    Joined:
    Nov 5, 2016
    Posts:
    363
    Simon was asking for diagnostics logs because we often discover issues in user projects or a particular package that is causing a slow iteration. (and for clarification, these are not telemetry but just local logs). When we see a user saying "my project takes 5-10min to open", we need more details to investigate (that was actually the case in this thread a few message before Simon suggestion). We definitely agree that it's not acceptable, hence why we ask for the diagnostics logs that can give more insights about what is going wrong. It could be something in Unity, or completely unrelated in user code project.

    I have lengthily explained in the entry of this thread that it is not that easy for many reasons. For example, part of the compilation pipeline was improved for 2021, and the team that worked on it benchmarked it for large projects using DOTS. But then, our users reported that it caused several regressions on much smaller projects (e.g the basic RT3D template). In the meantime of 2021, there were lots of other moving parts impacting iteration time: a lot more code and features have been added in C# so the JIT is taking more time while the engine is still main thread bounded, we didn't have benchmark tests for templates...etc, just even having multiple Unity tool window open can change dramatically the iteration time (and that's something that we don't track today), HDRP started to use Burst but that caused a massive slowdown of the compilation because it involves a lot more pieces in the compilation pipeline (IL post processing, Burst compiler). So we did work and are still working on these many moving pieces that have regressed here and there (compilation pipeline, Burst...) but there is a reality that to fix some of these regressions it's a lot more than a one line fix internally, and so it is more problematic or sometimes impossible to safely backport.

    It's going to be unlikely achievable for the many reasons I detailed above. 2019 is incomparable to what is shipped in 2021 in terms of the amount of C# code running at startup typically. So for example, reducing the cost of the JIT requires significant changes: 1) Move to CoreCLR that allows to AOT pre-compile .NET assemblies so that we wouldn't pay anymore the cost of the JIT, 2) Make the engine less main thread bounded so that we could offload more work on separate threads or separate processes. We have already started to work on1) but these kind of changes cannot be backported.

    So, we are still committed to improve the experience with 2021. We gave an update in January about it and we know that we are not yet back to something that is acceptable (e.g 1.5 to 2s for a RT3D template). Truth also that is that it can take sometimes a few months of work just to save 300ms (what has been happening since January), while we still have 2000ms to shave-off. So our teams are trying to do their best with the resource we have, and your feedback is important and listened up to the executive level.
     
  41. DragonCoder

    DragonCoder

    Joined:
    Jul 3, 2015
    Posts:
    578
    What I think some people here would prefer or would see as the right approach:
    The features, additional code etc. that resulted in this significant increase of time should have been caught at the time they were implemented - and due to their impact, a way to make the features optional might have been a good idea.

    On the other hand, I understand from personal experience how a growing project becomes slower and slower. It's very hard to avoid.

    Still it feels like something radical needs to be done that's not just pumping man hours into this which are needed in other places too. Perhaps removing the changes from LTS versions until they are fast enough or making them truly modular. Thing is, a main advantage systems based on interpreted languages like C# (but also Python for example) have, is normally fast iteration times (as opposed to engines that require recompilation) and this problem is throwing away that advantage...

    That said, it's clearly very project dependent (mine does not suffer that noticeably for example) - size alone isn't the culprit - and thus asking for the logs is surely a good idea.
     
    Last edited: Apr 29, 2022
  42. RobertOne

    RobertOne

    Joined:
    Feb 5, 2014
    Posts:
    183
    Now thats a Statement!
    And honestly a good one since it’s not giving us false hope. Thanks for explaining everything so well :)
     
    AcidArrow likes this.
  43. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    372
    @xoofx Thank you for continuing to address our concerns and working to improve the experience.
     
    TigerHix and xoofx like this.
  44. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    9,547
    So the tl;dr; is that since Unity decided to move (or invent new) features to C# world, even with much more optimization and greater code quality, and apparently there is considerable effort going towards that, further degradation of editor iteration year over year is simply unavoidable.

    I have no idea why Unity thinks it's a good tradeoff.
     
    Last edited: May 2, 2022
    DavidJares, akuno and rodrigonb like this.
  45. rodrigonb

    rodrigonb

    Joined:
    Aug 31, 2015
    Posts:
    4
    Does this mean that some user found an issue that was not present for you in your small project benchmarks? Or that you do not benchmark small projects at all?
     
    DavidJares likes this.
  46. richardzzzarnold

    richardzzzarnold

    Joined:
    Aug 2, 2012
    Posts:
    137
    Yes, it's great that Unity has so much added functionality and new features.
    Unfortunately it is has also now become essentially unusable.
    *slow clap*
     
    Last edited: May 13, 2022
  47. Neto_Kokku

    Neto_Kokku

    Joined:
    Feb 15, 2018
    Posts:
    1,357
    Seems if you want low iteration times you need to:

    - Use the oldest Unity version you can get away with.
    - Use as few packages as possible: use built-in pipeline, use legacy input, etc.

    Remember when C# had much better iteration times than C++?
     
    DavidJares likes this.
  48. xoofx

    xoofx

    Unity Technologies

    Joined:
    Nov 5, 2016
    Posts:
    363
    Yes, we did not have iteration time benchmarks for project templates (which can bring many packages) and for packages in general.
     
    DavidJares likes this.
  49. Der_Kevin

    Der_Kevin

    Joined:
    Jan 2, 2013
    Posts:
    516
    upload_2022-5-9_16-8-11.png

    2022.2 alpha 12 has some nice speed improvements! chapeau!
     
  50. jiraphatK

    jiraphatK

    Joined:
    Sep 29, 2018
    Posts:
    154
unityunity