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.
  2. Have a look at our Games Focus blog post series which will show what Unity is doing for all game developers – now, next year, and in the future.
    Dismiss Notice

Official Improving iteration time on C# script changes

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

  1. xoofx

    xoofx

    Unity Technologies

    Joined:
    Nov 5, 2016
    Posts:
    367
    Hello,

    Earlier this year, many users have reported increased waiting times (from 2s previously to 4s/6s) when changing one C# script + waiting for a domain reload on a simple Core 3D template or when entering Play Mode, in some 2020.x versions and newer 2021.x versions. We know how much iteration time during development is critical to your success and so, we are creating this post to centralize our communication about, and keep you better informed on the work involved on improving iteration time. Here are some links to previously reported issues:
    We have marked an issue with increased reload time as “closed” in our Issue Tracker. That doesn’t mean that we’re done investigating this issue, but the work involved to fix this regression spans across multiple versions of Unity, with multiple fixes from various different teams. And our issue tracking and release process is not suited for such a wide-ranging and long piece of work (usually one basic issue = one fix from one team). We want to keep you regularly informed about our progress, so we’re going to use this thread as a hub to:
    • Post regular updates
    • Collect additional feedback, especially whenever we have intermediate fixes that we would like you to help us validate
    First, thank you to all our users who have been reporting these issues and trying to help us find out what has been happening.

    These reports revealed that these regressions happened during some stages in the 2020.x release cycle, and that the situation hasn’t improved for 2021.1 or 2021.2. Now, why haven’t we been able to detect such regressions? While we do have performance tests, they were not fine-grained enough. As such, they were not tracking iteration time on templates like the Core 3D template nor were they tracking regressions that could be caused by packages. Also, at the time, we lacked fine-grained profiling markers in the Editor to detect the cause of such regressions and to correlate them between different editor versions.

    From our investigations in April earlier this year, we discovered multiple causes of these regressions:
    • Several locations have individually added a small increase in time (e.g. 20ms) but the number of locations made this worse (e.g. x50) generating at least around a second of domain reload impact, and vastly dependent on many variable factors (e.g. number of packages installed, number of windows opened or the layout).
    • A change in the compilation pipeline (deterministic feature in 2020.x+ and a new compilation pipeline in 2021+) helped to improve the situation for large solutions but made it worse for smaller projects or smaller changes (e.g. Default Core 3D template), impacting the domain reload by a second.
    • We had no good way to get in-depth performance metrics about domain reloads from users.
    • Around the same period of time, we also added some packages to the default Core 3D template, without taking the time to look at their impact on iteration time.
    The key problem that we found is that there was no “single” source of performance regression, but that:
    • Many teams at Unity had added functionalities that had a negative impact on domain reload performance.
    • It had totally gone under our radar.
    Therefore, we decided to work on different aspects of the issue in parallel:

    Domain Reload in-depth performance metrics
    Earlier this year, we added a lot of performance markers into the domain reload process, as well as a user-controlled option to add the measurements to the editor logs. This helps you see which component is taking time at which stage of the domain reload process (serialization / deserialization, InitializeOnLoad, Application events, Awake instances, etc.) in the editor log. We internally use this quite extensively now to track our progress, and we also made it available as a diagnostic switch in 2021.1 and later (see this message to learn how to enable it), so that you can give us detailed information about what happens on your machine during a longer-than-expected domain reload. You can also use this to quickly fix for Editor performance issues, when you see that for example a UI widget or an unused package have a significant impact.

    A task force dedicated to finding and fixing regressions across the whole code base
    We’ve also set up a task force led by our Scripting and Performance teams to identify any opportunity to optimize everything happening during both Script compilation and Domain reload.

    Here are the areas where improvements have been introduced positively impacting domain reload time for the upcoming 2022.1:
    • Type cache generation
    • Profiling tools
    • Menu population
    • Static batching
    • Particle prewarming
    • Visual Studio package
    • Terrain package
    • Polybrush package
    In the coming weeks, we will clarify which of these fixes can be backported safely to older editor versions (2021 LTS and potentially 2020 LTS).

    And here are the areas being currently worked on:
    • Script compilation (especially for small projects)
    • Optimizing IO and memory usage for projects with a large amount of C# scripts
    • MonoScript type resolution
    • Scene backup and updates
    • Visual Scripting package
    • Legacy plugin system
    These optimizations are sometimes done by the task force member themselves, or via direct collaboration with the team owning the relevant component. The Visual Studio Package initialization optimization, for example, has been implemented partially by the Scripting team, and partially by our partners at Microsoft.

    In addition to this work, we are going to add broader regression tests to track that changes happening in the Unity Editor/Engine codebase or in a satellite package aren’t slowing down iteration time.

    Some of those fixes are easily backportable to previous versions of Unity, and we will make sure that they land in patches for those versions as well. Some other fixes are in packages code and will require updating the packages you use in your projects.

    We will come back to this thread, as frequently as we can, to provide any important updates about our progress.

    We hope that this post helps to clarify the situation and gives enough insights about our determination to improve iteration time dramatically. We have learned a lot from this issue and we are confident that the tooling we are putting in place will really speed things up when it comes to improving iteration time for both large and small projects.
     
  2. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    5,957
    Is this fix about issue #1143037, where static batching n scenes on entering play mode in the editor actually batches 1+2+...+n scenes? That cost us ~60 seconds on enter play mode back when I reported it in 2019, but the bug report got "Our developers are currently working on other projects that are of a bit higher priority than this case."
     
    havokentity likes this.
  3. lyndon_unity

    lyndon_unity

    Unity Technologies

    Joined:
    Nov 2, 2017
    Posts:
    51
    This static batching optimisation isn't specifically related to that issue you listed. Thanks for highlighting it. I'll discuss it with the team that made the new optimization to see if we can make gains there too.

    The optimization listed above was to move the static batching work to happen in parallel across available cores, greatly speeding up the time taken on multi-core machines.
    There is also a secondary optimization which speeds up the sorting phase by removing some unnecessary logging.
     
    Niter88 likes this.
  4. JoNax97

    JoNax97

    Joined:
    Feb 4, 2016
    Posts:
    597
    I just want to chime in to say that this type of communication is very valuable and appreciated. Thank you!
     
    Niter88, ianjirka, LudiKha and 24 others like this.
  5. DoctorShinobi

    DoctorShinobi

    Joined:
    Oct 5, 2012
    Posts:
    212
    I agree with joNax. It's good to know Unity is aware of this issue, is taking it seriously, and is actively working on getting this fixed. Good job!
     
  6. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    390
    Thank you, xoofx.

    Including the fixes described above -- is parity with 2019.x achieved? I don't think the task force should rest until iteration returns to sub second.
     
  7. Seith

    Seith

    Joined:
    Nov 3, 2012
    Posts:
    755
    Thank you for communicating about this important issue, xoovf.

    Now I really hope management doesn't pull you guys away from that and put you on other "priorities". Fingers crossed.
     
    xoofx likes this.
  8. xoofx

    xoofx

    Unity Technologies

    Joined:
    Nov 5, 2016
    Posts:
    367
    It is unlikely that we will get to strict parities because in the meantime, more features have been added. But we hope to get back to an iteration time that is between 1s to 2s for a simple project changing a single C# script of the main assembly.

    There is a hard limit also in how much code we can run on the main thread, and moving this code in separate threads will require a lot more substantial work than the optimization done for mitigating the recent regressions.
     
  9. sameng

    sameng

    Joined:
    Oct 1, 2014
    Posts:
    151
    I really appreciate the update, thank you xoovf and team.
    This is such an important issue to me, it makes me feel a lot better having this acknowledgement.

    Please let us know how the community can help. Whether it be profiling data or even uploading whole projects, if that helps. I know I'd be happy to provide, if it proves useful.
     
    reinfeldx and Jes28 like this.
  10. bac9-flcl

    bac9-flcl

    Joined:
    Dec 5, 2012
    Posts:
    825
    I appreciate this update!

    I wanted to focus on briefly mentioned detail in particular: as much as possible, it would indeed be great if all fixes are ported to 2020 LTS. I understand that this is caused by a multitude of factors, some more recent then others. But for parts that originate from changes in Unity 2020, it would be good to rectify them for 2020 LTS - not every project has ability to jump to 2021 and getting stuck with permanently slowed down iteration time wouldn't be ideal.
     
  11. Novack

    Novack

    Joined:
    Oct 28, 2009
    Posts:
    815
    Agree with @stonstad and got surprised by that answer... sorta asumed the final objective was to return to previous iteration times, independently of how many features are added to the engine. If we are going to be losing seconds to every thingie that Unity introduces, the whole thing would be unsustainable in a matter of months :eek:
     
    Ziflin likes this.
  12. stuksgens

    stuksgens

    Joined:
    Feb 21, 2017
    Posts:
    172
    Thanks for the updates

    We are currently at 2019LTS, and we want to migrate our projects to 2021 LTS (as soon as it is available)
    Would it be possible to have these optimizations landing on the 2021 LTS tech cycle?
     
    havokentity likes this.
  13. Innovine

    Innovine

    Joined:
    Aug 6, 2017
    Posts:
    488
    Is it possible to turn off the auto compiling, and manually trigger it when I want to? after I hit save in VS unity turns unresponsive for up to 10 secs, and only then does the green percentage bar appear, for another 5-6.
     
    cips6768, Baldrekr, pmurph03 and 2 others like this.
  14. Per-Morten

    Per-Morten

    Joined:
    Aug 23, 2019
    Posts:
    90
    If I understand you correctly, then you can do that from Edit -> Preferences -> General and turn off Auto Refresh and Directory Monitoring. When you need Unity to compile/refresh, hit CTRL+R. Just know that if you forget to hit CTRL+R then you won't have the newest changes from your script in Unity. I ended up creating a new button in the editor that I use instead of play mode that refreshes first so I reduce the chance of going into playmode with old scripts.
     
  15. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    5,957
    Try to compare it to making a script change in Notepad. This could be VS acting up - it often does.
     
    havokentity likes this.
  16. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    390
    That's a brilliant work-around! Would you mind posting your button source on a Gist?
     
    Bunny83 likes this.
  17. Per-Morten

    Per-Morten

    Joined:
    Aug 23, 2019
    Posts:
    90
    Last edited: Oct 20, 2021
    pKallv, Bunny83, PutridEx and 5 others like this.
  18. strich

    strich

    Joined:
    Aug 14, 2012
    Posts:
    309
    Reading this thread has alone regrown some hairs on my head. Thank you @xoofx I know you personally push for a lot of boring/subtle but ultra important improvements behind the scenes!

    What would be the ideal way to present additional problem areas for this? For example, our project has become extremely laggy with the in-editor experience over the past couple of years. Here is a quick example of me interacting with a couple of drag-n-drop elements:

    We've done our best to debug and isolate the root cause but its been too hard without deeper metrics into Unity Editor.
     
  19. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 20, 2015
    Posts:
    8,745
    If you don't want to learn a new button and an extra window, just put it in a file in an Editor folder:
    Code (CSharp):
    1. using UnityEditor;
    2. using UnityEngine;
    3.  
    4. public static class EnterPlayMode
    5. {
    6.     [RuntimeInitializeOnLoadMethod]
    7.     private static void Init()
    8.     {
    9.         EditorApplication.playModeStateChanged += OnEnterPlayMode;
    10.     }
    11.  
    12.     private static void OnEnterPlayMode(PlayModeStateChange obj)
    13.     {
    14.         if (obj == PlayModeStateChange.ExitingEditMode) AssetDatabase.Refresh(ImportAssetOptions.Default);
    15.     }
    16. }
    17.  
    Note for people who read this out of context: read the thread. This editor script should only be used when you turn off the directory monitoring and auto refresh. If you don't have problems with your code editor and Unity editor working together by default, it isn't for you, probably.
     
    Last edited: Oct 20, 2021
  20. Per-Morten

    Per-Morten

    Joined:
    Aug 23, 2019
    Posts:
    90
    Ok, that's way better, thanks :)
     
  21. Innovine

    Innovine

    Joined:
    Aug 6, 2017
    Posts:
    488
    I must say, this has made a VERY surprising difference. Just by disabling Auto Refresh and Directory Monitoring, when I make a change to a script and alt-tab to unity and hit Ctrl-R its at least 10-15 seconds faster. Plus it's eliminated all those times where I didn't need care about a recompile and wasted my time waiting for the editor to respond again.
     
    Ziflin, ArtemVy and stonstad like this.
  22. JezMK

    JezMK

    Joined:
    Mar 19, 2021
    Posts:
    5
    This issue "Scripting: Increased Script Assembly reload time 1323490" was referenced in the past 5 LTS releases for 2020.3.x, other than the last one, as a "known issue". In the latest release, 2020.3.21f1, there's no mention of it.
    Is it now fixed, or just missing from the known issues list?
    Thanks!
     
    HugoClip likes this.
  23. print_helloworld

    print_helloworld

    Joined:
    Nov 14, 2016
    Posts:
    227
    Theres a better way, you can actually screw with the play mode states in editor so that when you press play, you can run custom code before it enters play mode. The ninjas approach is good too, its pretty much the snippet here but theirs runs later in the flow (mine runs as if it just ran before you pressed play)
     
    Per-Morten and Munchy2007 like this.
  24. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    390
    FYI. I converted to 2021.2. I'm not seeing any meaningful changes in editor iteration time. I understand the majority of improvements are slated for 2022.1. I'm looking forward to it.
     
  25. sameng

    sameng

    Joined:
    Oct 1, 2014
    Posts:
    151
    While doing some compile tests for the new M1 Max, I also had a chance to compare the domain reload times for 2020.3.21 vs 2021.2, on my intel i9.


    Sadly, it looks like 2021.2 has regressed further in performance. On the same machine, same project etc, it is approximately 10% slower than 2020.3.

    The Compile times are superduper fast now, but the Assembly Reload, which is the true cause of slow developer iteration time, has regressed.

     
  26. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    390
    @xoofx

    2021.2 is measurably worse than 2021.1.x. From a deep iteration profile I am seeing duplicated effort which manifests randomly.

    1) AssetDatabase.Refresh occurs twice. Once in AssetImport and again on AssemblyReload.
    2) Application.UpdateScene occurs twice. Again, once in AssetImport and again in AssemblyReload.

    I don't always see this duplication. But when it happens the iteration hit is 35s instead of the 'normal' 12s (see above). I am including exported profiler data as well as a screenshots documenting the same.

    I can't stress enough how damaging this is to productivity and workflows. All hands on deck, fire on the bridge.

    Screenshot:
    upload_2021-10-28_10-42-7.png

    Export:
    https://tonstad.blob.core.windows.net/media/EditorIterationData_2022.2.0.zip (6MB, .CSV and .JSON).

    Support Ticket:
    FogBugz 1376641
     
    Last edited: Oct 28, 2021
    cips6768, KYL3R, joshcamas and 14 others like this.
  27. WinterboltGames

    WinterboltGames

    Joined:
    Jul 27, 2016
    Posts:
    244
    I noticed the exact same thing in my own projects.

    I'm pretty sure this definitely has something to do with Visual Studio (or more precisely the Visual Studio Editor package). I've tried doing edits in Notepad++ and Rider and both of them don't result in that function getting called twice at least for me.

    On the bright side, it seems that 2021.2 makes building for both Windows and Android a lot faster without touching any settings. Clean builds took 10-15% less time compared to 2021.1, 2020 LTS, and 2019 LTS.
     
  28. Seith

    Seith

    Joined:
    Nov 3, 2012
    Posts:
    755
    @xoofx

    We're now on 2021.2.0f1 and we can say this new version has made the "Fast Enter Play" mode twice slower. In 2021.1 we were able to enter play mode 4 seconds after hitting the button. We now have to wait for 9 seconds.

    This is a problem.
     
  29. kloot

    kloot

    Joined:
    Mar 14, 2018
    Posts:
    40
    Huge problem. The no. 1 reason many of us keep updating Unity is to get faster compilation and play mode times (which is always touted as being improved), yet when I measure the results, it's always the exact opposite...

    It's good that Unity finally acknowledge this bizarre take on "progress" - now please devout all possible resources to rectify this travesty...
     
    StellarVeil, Arkade, Ziflin and 4 others like this.
  30. lawsonh

    lawsonh

    Joined:
    Jul 25, 2018
    Posts:
    79
  31. kloot

    kloot

    Joined:
    Mar 14, 2018
    Posts:
    40
    Oh, yes. Been doing that since 3 years - don't expect much... While it certainly does speed up compile times in your code editor, as soon as you switch back to Unity it seems to recompile everything as if you didn't have the asmd-files in the first place. Making your with a net win a solid 0.
     
    Last edited: Nov 3, 2021
  32. mahdi_jeddi

    mahdi_jeddi

    Joined:
    Jul 18, 2016
    Posts:
    216
    Just updated to 2021.2.0f1 and sometimes getting error when changing the code too often in Visual Studio:

    Library\ScriptAssemblies\Assembly-CSharp.pdb: Copying the file failed: The process cannot access the file because it is being used by another process.


    This is on top of 20 seconds of Reload Assemblies message. I already made a bug report Case 1376324.
     
    pmurph03 and castor76 like this.
  33. print_helloworld

    print_helloworld

    Joined:
    Nov 14, 2016
    Posts:
    227
    aromana and stonstad like this.
  34. ubbelito

    ubbelito

    Joined:
    Sep 24, 2018
    Posts:
    23
    Isn't the underlying problem here that no one at Unity use the editor themselves? Even on toy projects, it is immediately obvious how painful the turn-around time is.
     
  35. Adrian

    Adrian

    Joined:
    Apr 5, 2008
    Posts:
    826
    I'm always a bit surprised how game developers, of all people, can lack the basic imagination for how impossibly difficult managing a project at the scale of Unity has to be. Sure, blame them for not delivering! Call them out for their failed strategic decisions! But suggesting no one at Unity is using their own product or doesn't take user feedback very seriously is just lazy.
     
  36. aromana

    aromana

    Joined:
    Nov 11, 2018
    Posts:
    137
    I think you might be missing their point. I doubt they were suggesting nobody at Unity uses Unity, but rather that Unity employees might not be living with the product for day-to-day substantial game development.

    And I think this is true — as far as I know, Unity does not own or operate a game studio, so presumably there aren't Unity employees whose full-time job is to build large, multi-month or multi-year projects in Unity. The problem discussed in this thread is one that would only tend to weigh on someone if they're building larger games, iterating dozens (or hundreds) of times a day, every day.

    This is not true of, say, Unreal Engine (which has plenty of its own flaws to be clear!) but I'd wager the feedback loops at Epic are tighter than Unity, since Epic has hundreds of people on staff using the engine to build large-scale shipping games (Fortnite, Gears of War, etc), in addition to lots of folks working on the engine.
     
    hoesterey, Novack, Ziflin and 9 others like this.
  37. kloot

    kloot

    Joined:
    Mar 14, 2018
    Posts:
    40
    I feel we have to be honest about the fact that when so many of us have been getting more and more frustrated for several years and Unity not even noticing, then there's a pretty unhealthy disconnect between the makers and the users of the tool.
    Paying closer attention to the forums might help. Having turnaround times a clearer (and measured) priority might help. Dog-fooding the editor would definitely help - hard not to notice how bad things have gotten if you're an actual user of this thing.
     
    Novack, Ziflin and stonstad like this.
  38. mahdi_jeddi

    mahdi_jeddi

    Joined:
    Jul 18, 2016
    Posts:
    216
    For us sometimes the reload times go over 20 seconds. I checked the logs and it's CreateAndSetChildDomain (16126ms). It doesn't have any child items and everything else was normal. Hope this helps.
     
    dannyalgorithmic and stonstad like this.
  39. ubbelito

    ubbelito

    Joined:
    Sep 24, 2018
    Posts:
    23
    I am not suggesting they don't take user feedback seriously. I am also not suggesting that they don't open the editor during development to test changes that are made. My point was that they don't use the editor for actual development. Dogfooding, in other words.

    Let me quote the beginning of this thread:
    Earlier this year, many users have reported increased waiting times (from 2s previously to 4s/6s) when changing one C# script + waiting for a domain reload on a simple Core 3D template or when entering Play Mode, in some 2020.x versions and newer 2021.x versions.

    Clearly this was caught by the users and not Unity themselves, or they didn't consider it important enough to report internally or in beta. Again, this thread suggests that the problem is considered important but it was not caught internally.

    My point stands: If Unity was using the editor themselves for real development, this would have been fixed because the impact on productivity is immediately noticeable.

    Edit: I will grant you that it is entire possible that product owners don't take internal feedback seriously.
     
  40. Neto_Kokku

    Neto_Kokku

    Joined:
    Feb 15, 2018
    Posts:
    1,521
    See the recent update for both 2019 and 2020 LTS versions which broke shader compilation when making builds using batch mode with -nographics (rendering most CI setups useless) as a good example of lack of proper dog fooding.
     
    goncalo-vasconcelos likes this.
  41. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 20, 2015
    Posts:
    8,745
    You're wrong.
     
    HyperionSniper likes this.
  42. kloot

    kloot

    Joined:
    Mar 14, 2018
    Posts:
    40
    If he/she is wrong, how come they admittedly didn't notice what they now had to assign a task force to fix?
     
    Last edited: Nov 4, 2021
    andreyefimov2010 and Ziflin like this.
  43. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 20, 2015
    Posts:
    8,745
    This is a complex question.

    First of all, working on a real game doesn't provide what you are looking for. Game development doesn't happen on this way. If you start a project, you do not (well, you should not) upgrade your editor (and your engine and tooling, etc) under it unless in exceptional circumstances. Which means if Unity made a game, they wouldn't use the beta version of the editor. This is why this argument is incredibly silly.
    Second (and it ties back to the first point), their clients (where most Unity employee using Unity Editor as a game/film/etc development tool) are professional developers, usually studios. Professional developers don't use unreleased or freshly released tools unless it's an exceptional emergency.
    Third, you're assuming that this few dozen forum developers are the majority of users, but they/you aren't. For the majority of users these problems usually simply don't exist. Maybe some special hardware cases, interference with other software/hardware, using HDD and not keeping it defragged, and so on, there can be many different reasons that some people see a problem, but others don't.
    The point is, Unity has millions of editors installed on millions of people's devices, and they don't see millions of complaints.
    And finally, now had to assign a task force because they found some problems, which may be fixable by them counting with the cases you people provide(d). This is why submitting bug reports is crucial. You can't assume that they know about it, because today's computers are incredibly complex machines, you maybe the one, who sees the problem. Or maybe just member of a small group. If you don't report it, it can stay and bother you because the majority just can't see it. And I deliberately used the "you" here, because for example I experienced literarily none of these issues (although I may just got lucky with one or two, it works both ways).

    Edit, I forgot to add: Unity also is working on extensive demos all the time. Like they do this forever. All those teams are also using Unity on a day to day basis. Adam demo, BotD, Blacksmith, Island demo, etc don't appear out of thin air. People are spending time in the editor realizing those.

    Disclaimer: I am a software engineer for 23 years now for a living and tinkering with software for 32 years. I was member of many teams who were responsible for user-facing software. I saw this from the other side of the table many times.
     
    Last edited: Nov 5, 2021
  44. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    9,611
    It doesn't matter if they use Unity or not. Employees of Unity using the engine doesn't mean their manager will tell them to focus on making the editor faster and nicer to use.

    And Unity (the company), clearly did not have editor user experience as a priority for many years and now they (and we) are paying the price. One year of placing editor user experience higher on the priority list isn't enough to fix that (even if we take them at their word).

    And dogfooding doesn't really matter. I'm pretty sure many employees know the issues. Whether they are allowed to work on them is another thing.

    I think the only effective form of dogfooding would be if we took all upper management and made them make a good indie game using Unity (the goal would be to release a game on steam for 15$ and it would have to get reviewed by prominent press and get at least a 7/10 overall), and somehow make their livelihood dependent on whether they succeed at that. You could even make a reality show out of it. I would so watch that.

    I'm pretty sure then priorities would change towards making Unity good to use, and not just look like it is good to use.
     
    Anthony0506, Novack, NotaNaN and 2 others like this.
  45. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    29,722
    Sorry Tim, you can't use Fortnite to battle test Unreal Engine 5, even though you announced you would, because Lurking-Ninja said so.

    And there is plenty for Unity to discover how broken or ill contrived their engine is by trying to get a large game working in the LTS or Tech stream. There's no excuses here for me. I understand that it's probably never going to happen, but it doesn't mean the company shouldn't act if thought they were working on one with much more focus on optimisation.
     
  46. castor76

    castor76

    Joined:
    Dec 5, 2011
    Posts:
    2,423
    I also get this, and I have to restart Unity when it happens to continue to work. So frustrating.
     
  47. mahdi_jeddi

    mahdi_jeddi

    Joined:
    Jul 18, 2016
    Posts:
    216
    My solution now is to add a new line and save it until it shows the "Load Assemblies" message. Sometimes it takes quiet a few tries, but usually faster than restarting the Editor.
     
  48. davidnibi

    davidnibi

    Joined:
    Dec 19, 2012
    Posts:
    409
    Is this related to this problem - it seems to lag on v2021.1.23 even on the simplest of functions, such as:

    Capture.JPG
     
    Radivarig likes this.
  49. mahdi_jeddi

    mahdi_jeddi

    Joined:
    Jul 18, 2016
    Posts:
    216
  50. castor76

    castor76

    Joined:
    Dec 5, 2011
    Posts:
    2,423