Search Unity

  1. We would like to hear your feedback about Unity and our products. Click here for more information.
    Dismiss Notice

Feedback An everlasting cry for editor performance/stability/scalability++

Discussion in 'Editor & General Support' started by Xblade-Imperium42, Jun 8, 2019.

  1. Xblade-Imperium42

    Xblade-Imperium42

    Joined:
    Jan 12, 2016
    Posts:
    599
    While it's great that Unity focused on performance-first for end-users, devs spend up to 12 hours per day using the Unity editor. The editor, when using anything remotely advanced or large in size, becomes miserable to work with. After years, developers are begging to spend a few versions for editor performance/stability -- this will also benefit end-users as devs will be able to deliver faster, more-efficient results with higher morale:
    1. AsyncOps. They are incredibly unstable. Reproduced on every PC I've used Unity with, active SyncOps within the editor will cause numerous, breaking issues that turn 5-minute task into 2 hours. This only happens in the editor - not in standalone.
      • GIF Repro: http://recordit.co/ytJFfHyPPu

      • Within the editor, scenes preloading or preloaded to 90% (not yet active) with AsyncOps will cause scenes to prematurely fire to the next scene. This means if I alt+tab over to Visual Studio to step through, or even to Chrome to browse, upon returning I will always fire to the next scene.

        SceneManagement callbacks will not even detect the oldScene because the scene was not even supposed to fire. So if you have a chain of scenes with AsyncOps? Yep, a chain reaction -- it's a horrible experience.

      • Since Async/Additive scenes are the way of life for any professional/commercial game to prevent hiccups in loading, everything is async/additive, these days (or should be). However, this also means that debugging is hell because of bugs like the above one.

      • If an AsyncOp is running in the background, it messes up debugging with Visual Studio: Entire blocks will just randomly be stepped over unless you explicitly have a break point; if a Debug.Log() is the first line of a function, it'll auto-step into it and if you step out, the entire block is skipped (again, unless you explicitly have a breakpoint); this goes on and on -- stepping through is inconsistent and chaotic, only when AsyncOps are present (or anything async, to be honest).

        Many experiences stepping through Visual Studio will result in a crash because Unity+Async anything+VS do not get along together. Debugging async tools with WinForms is fine, so it seems to be narrowed down to Unity Tools for VS.
    2. Larger Projects and unacceptable compiling scope/time. With my project with 5gb worth of assets and a large [local] cache, it takes anywhere between 10 to 60 seconds to recompile a single comment change, freezing all threads - and this is with an i7-8700k CPU (poor folks that have an i5. I used to have an i5, and it took me up to 2 mins - and that was when my project was smaller).
      • If I change test.cs to add a single letter to a comment, my entire project recompiles. Even if my scene doesn't even use this file, all threads are frozen for 10 to 60 seconds - not this single file, but the threads freeze while it scans my entire project for changes -- whether if it's in my scene or not.

      • Unreal, for example, has butter-smooth recompiling on this matter -- why can Unreal handle this, but Unity can't?

      • Why can't I multitask when I'm waiting for my +comment in my file that's not even in my scene? Why is the entire project scanned for changes freezing all threads during this time when competitors clearly found a way to prevent this? Is this actively being tested to help your mass crowd of users get through the day without taking a break every few seconds? The last I heard, Unity tried this, then silently ditched the feature when it should really be high priority since this consumes a devs time more than anything.
    3. Compiling + error detection. Why would common/simple building errors be detected at the end of compiling to cancel the entire operation that could have easily been tested at the beginning with only a few seconds actually consumed for these tests? It's like waiting in line at the DMV, then having a sign that you need a ticket at a different building AT the counter instead of at the beginning of the line: It could be prevented with a single change.

    4. UI editor bugs not fixed leftover for years. ScrollRects or any form of content holder (or layout groups) combined with anchoring. Text will randomly shift outside where it's supposed to be. You have to click play then stop, and it'll bounce back to where it was. Text that suddenly decides to go all black or blocky until you play then stop. All types of these bugs not fixed, existing since Unity 5.5. Here's a collage just for that:












    ...and this is just what I've taken note of because I've seen it over and over. AsyncOps and the thread-blocking recompile times (for out-of-scope files, even) are the worst one, for me, or debugging anything async when it comes to breakpoints.

    It becomes depressing over time. We beg you - please take just a couple major updates to focus on the developers: That means EDITOR performance/stability. Happy devs are happy publishers are happy consumers.
     
    Last edited: Jun 8, 2019
  2. Peter77

    Peter77

    Joined:
    Jun 12, 2013
    Posts:
    3,601
    I also struggle with editor performance a lot. It feels like every new Unity release caused the editor to get slower.

    To be honest, I actually stopped working on my spare-time Unity project, because the editor turned so slow over the years, that I'm not interested in it anymore.

    I started the project with Unity 4.6 and the editor felt responsive and I had a blast working with it. I updated the project over the years to keep up with Unity releases and observed how editor performance got worse (1, 2, 3, 4, 5, 6, 7, 8). I recently upgraded my project to 2018.4, just for the sake of it, but it's too slow to work with it. For fun I also tested 2019.2 and 2019.3 recently, but it got even worse.

    This is a real bummer, because I do want to work on my project and I do want to work with Unity, it just won't happen, if I have to wait most of my time on the editor.

    Have these issues been reported through the Bug Reporter tool? From my experience, if there is forum post, but no bug-report, Unity Technologies might not be aware of the problem. Don't forget that Unity developers participate on the forums voluntarily (link).

    If you're interested to get a bug fixed, you have to submit a bug report as explained in this document and provide them with a reproduce. I know that submitting a proper bug-report requires more effort than posting in the forum, but it's the most reliable way to get things fixed in my opinion.
     
    Last edited: Jun 9, 2019
    5argon and SugoiDev like this.
  3. Homicide

    Homicide

    Joined:
    Oct 11, 2012
    Posts:
    214
    100% agree First of all, don't get me wrong, I do love unity. Use it every day for far too many hours a day, especially the last year or two. But on and off for several years i have been using unity, and as unity has grown, it feels like it has become less stable, slower, and broken all round... (Looks at UNET / InputManager, and the lack there of).

    I'm actually posting now after Unity 2018.4.f1 has crashed again for no known reason what so ever, as it does at least 3 or 4 times a day. And this is an LTS version... ? I attempted to give new 2019 versions a go, but they were literally un-useable on so many fronts.

    I think what perturbs me most these days , is that versions are being pushed and announced far too long before they are relevant, and they are literally next to un-useable. And in some cases, completely defy logic, imo. For eg, car dealers have been doing it for years. advertising and selling a new car with a model make date of a year that .... wait , hasn't even come yet? Just like unity 2019 was downloadable and circulating, when we were all in the year 2018. Its prolly just me, but i think its ridiculous.

    There's no point what so ever to a new version if a past version (or, ALL past versions) are still plagued with issues. Now again, i'm quite content with unity 2018.4 LTS , but to say that it has been worked out and kink free is a far cry. We don't need new versions, we need fixed solid LONG TERM SUPPORT versions. And maybe a few addons (replacements) for the long time broken interfaces. **looks at UNET, again...**
     
  4. Zuntatos

    Zuntatos

    Joined:
    Nov 18, 2012
    Posts:
    522
    It isn't viable to do business as a dev team of 500-1000+ to <all> work on bug fixes of the existing version before starting on future projects. There's a bug fix team, there are teams for every part of Unity fixing their own bugs, whatever. Other teams will work on a future project, and their work gets into the next version that becomes the beta. Or the one after that.

    But on-topic: I run into some of these issues as well.
    Sometimes I exit and an async scene load completes after it, and I end up with inactive scenes loaded in my "start" scene breaking further play tests until I manually unload them. Maybe this is me not cancelling/disposing of something, but I would assume finalizers run on everything when exiting playmode (?).
    Sometimes the text fonts break for no obvious reason until you stop-start.

    My compile times are okay though (few seconds) which is interesting as my game is fully procedural except half the UI so there's much code. Upgrading from 5.6 to 2018.4 also went mostly without problems.

    I do feel like unity should keep some people dedicated to working on 'older' systems getting in depth knowledge of them to fix bugs (or *more* people doing this, they probably have some).
     
  5. SugoiDev

    SugoiDev

    Joined:
    Mar 27, 2013
    Posts:
    222
    Yeah, I feel you. Have some stuff to release/maintain, but I'll probably not be using Unity with our future projects until the development performance improves.


    At-best linear time with number of types/files/assets reload times simply does not scale well. I remember the Ori devs having to wait several minutes to enter playmode. Imagine all the wasted developer time.

    Developer time is very expensive and should be respected as such.


    I have some hope that the Editor will finally be responsive at some point in the future with DOTs and friends, but after waiting for so many years I'm kinda tired.
     
    Peter77 and Xblade-Imperium42 like this.
  6. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    1,661
    Break your project into asmdefs.

    At least into two. One containing all third party code, and the one for your code.


    Agreed on the rest of the points.
     
  7. TurboNuke

    TurboNuke

    Joined:
    Dec 20, 2014
    Posts:
    55
    Having tried all the different techniques to speed up compiling / entering play mode / adding new objects etc. I finally just had to buy a much more powerful PC just to get work done. Luckily we make money from our games, but for most breadline indie devs, it's a horrible situation if you have a large project.
     
  8. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    4,631
    Turning off auto refresh in Unity, and get just to refresh manually, will be your huge performance bust.
    I switched long time ago and never look back.
     
  9. f0ff886f

    f0ff886f

    Joined:
    Nov 1, 2015
    Posts:
    139
    I'm not going to say there's any fixes, but this is a problem that exists for years. There was another thread about similar slowness: https://forum.unity.com/threads/edi...s-to-enter-playmode-in-an-empty-scene.516004/

    For me, its about a 52 second feedback loop between hitting ctrl+s in vscode and having playmode running. It's insane. I don't know if the Unity devs have ever actually worked on a large-ish (I doubt my project could be considered large) project, but its horrible. Put a counter on recompiles in a small Unity project, and make each one take one minute. It can take hours to debug complicated gameplay-behaviour issues because you spend hours waiting on the feedback loop. The only stuff its quick to diagnose is things you can easily glean from the debugger.

    There's so much to like about Unity, but the abysmal developer experience in a large project is not part of that group.
     
    alexeyzakharov likes this.
  10. SugoiDev

    SugoiDev

    Joined:
    Mar 27, 2013
    Posts:
    222
    Completely agree. And it doesn't even have to a large project. Just a few hundred assets with a few thousand types is enough to make it crawl.


    I'm testing 2019.3 alpha here and the new feature to enter playmode without reloading the domain (and/or scenes) is incredible.

    At least non-programmer folk will now be able to iterate fast. A huge thing for me is that I won't have to "duplicate" playmode features for editor-side stuff anymore. I probably spent at least 20% of my time dealing with that, so that non-programmers (artists, designers, sound people) would be able to iterate fast without having to enter playmode.

    With this new change in 2019.3, I can finally sunset some of my edit-time integration stuff.


    The missing things now, for me

    * better assembly reloads for our edit-compile-play iterations. This one hurts a bunch, especially during long debug sessions. I'm pretty sure they can halve the current times just by removing LINQ and being careful with strings during the reload phase. LINQ is not suitable for such a hot path (at least in its current, unoptimized state).

    * (off topic) better profiler performance. The profiler has improved a lot, but it still suffers massively when we try to debug anything related to domain reloads and the editor itself. It would probably benefit from being a standalone native application, instead of C#. But, maybe burst and DOTs will help with that.
     
    alexeyzakharov likes this.
  11. 5argon

    5argon

    Joined:
    Jun 10, 2013
    Posts:
    1,194
    I also have several bug report on UGUI collapse based on Aspect Ratio Fitter. It's a shame that this component is the final key to achieve my design especially with nested prefabs. (So user of this prefab and variants could do a different stretch in their own rect that retains proper looks) In Unity it's always a tiny bit away from discovering a preferred workflow only to be blocked by a bug. I also can't animate UI by rotation without having to put up with hundreds of flooding warning about not able to restore them since 2017-2018 or so.

    https://fogbugz.unity3d.com/default.asp?1158131_n32m4ofuuf1q1iup
    https://fogbugz.unity3d.com/default.asp?1157733_dg3e2p8pdj5cons5
    https://fogbugz.unity3d.com/default.asp?1151100_96oj204edfrldnlf

    As for play mode iteration problem I have expressed my thoughts here but they are mostly similar to yours : https://gametorrahod.com/objectively-comparing-unity-and-unreal-engine#play-mode-iteration-flow

    The real problem I think, is that DOTS will fix everything. (e.g. systems could be hot reloaded safely individually retaining data, systems has no domain to reload, etc.) The reason that's the problem since they may not want to invest to fix problems in the old architecture when they see how things will work out in a new way. And DOTS rebuilding is far from done (2022).
     
    Last edited: Jun 11, 2019
  12. phil-Unity

    phil-Unity

    Unity UI Lead Developer Unity Technologies

    Joined:
    Nov 23, 2012
    Posts:
    1,137
    Any chance you've filed bugs on these topics? Aside from the Text being garbled (which btw i've looking into multiple times but no good repo so its eluded me thus far so if you have a good repo of that please i'd love to get it) i dont think i've seen any of the positioning issue come across the grabbag. Now i dont know if its getting filtered out before i see it but if you have filed some bugs by all means send them my way either here or in a DM. If you've not filed bugs then please do so, as i cant fix what i dont know is a issue.
     
    Peter77 likes this.
  13. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    411
    If you have your assembly dependencies setup in way where your project only recompiles 1 assembly when you iterate, then compilation should be relatively fast. You can check whic assemblies are getting recompiled in the Editor.log where they compilations are logged with "Starting compile" and "Finished compile". Unfortunately we do not log the compilation times currently, but you can log these yourself by using

    https://docs.unity3d.com/ScriptRefe...ationPipeline-assemblyCompilationStarted.html
    https://docs.unity3d.com/ScriptRefe...tionPipeline-assemblyCompilationFinished.html

    If you have the assembly compilation setup under control, then it is probably the reloading of assemblies that takes the majority of the time. Typically due to C# code in the project, either user code or third party code.

    I've written a forum post about how you can profile this here.

    https://forum.unity.com/threads/example-project-assembly-definition-files.482313/page-3#post-3292894

    Is this for building the player or for iterating in the editor? Could you perhaps provide an example of this for me to get a better understanding of the issue?
     
    Peter77 likes this.
  14. dgoyette

    dgoyette

    Joined:
    Jul 1, 2016
    Posts:
    1,714
    Hey @lukaszunity, I'm not sure what the OP's exact use-case is, but I believe I know what he's referring to. Here's a simple example I hit fairly often.

    I have a few areas of code surrounded with #if !UNITY_EDITOR, such that it only goes into a build, and doesn't run in the editor. Sometimes I end up with compilation errors in this code that I only notice when creating a build, since that code is only compiled when building, not while working in the editor. Unfortunately, the build error related to this seems to occur very late in the build process, after some other long-running processes, like shader compilation, have taken place.

    For me, a typical build is 2-3 minutes, most of which is shader compilation time. The build takes just about the same length of time whether I have one of these #if !UNITY_EDITOR compilation errors or not. Ideally those errors would have been detected by Unity before it started the lengthy shader compilation phase of the build.
     
    Peter77 likes this.
  15. Mads-Nyholm

    Mads-Nyholm

    Unity Technologies

    Joined:
    Aug 19, 2013
    Posts:
    92
    Have you submitted a bug for the above repro? If not we would appreciate if you took the time to do it so we can investigate your use case.
     
    Peter77 likes this.
  16. Ryanc_unity

    Ryanc_unity

    Unity Technologies

    Joined:
    Jul 22, 2015
    Posts:
    201
    That's interesting, building scripts and failing the build if there are script errors is the 2nd thing we do already, right behind switching to the build target platform if that is not already the target platform. Are you by chance frequently building for a built target other than the currently active platform?
     
  17. Xarbrough

    Xarbrough

    Joined:
    Dec 11, 2014
    Posts:
    376
    The original post lists a few different issues, but I would like to voice my concern for the overall topic of editor performance and stability as well. Our team is seeing an awful decline in editor performance over the years (since 2014). I personally profile the editor regularly, but the biggest issue is not any single item, but the amount of non-optimized code Unity is running.

    One of the biggest culprits seems to be a constant check for specific Assembly attributes, such as looking for CustomTools attributes, InitializeOnLoad, etc. We don't actually implement any of such callbacks ourselves, but the editor spends a lot of time and GC on retrieving arrays of attributes. I also feel like SceneView drawing has gotten slower and slower without anything specific standing out. When I look at the profiler, I see 60ms drawing time each SceneView update, but when I drill down, its just a callstack 50 items deep and at the end we see some handle drawing with 0.4ms, but because there are so many functions and systems involved its slow. A lot of it also looks like internal performance tracking, analytics and workarounds to upgrade systems such as IMGUI to UIElements. I know we all want these new features and the transition should be smooth, but I believe a lot of the performance drawbacks can be resolved by simply writing more performant editor code.
     
    SugoiDev, alexeyzakharov and Peter77 like this.
  18. Xblade-Imperium42

    Xblade-Imperium42

    Joined:
    Jan 12, 2016
    Posts:
    599
    This was the best thing I've ever read. You've changed everything for me. It's literally like how Unity was when I first started! It's THE advertised Unity experience! Only now I have to remember to CTRL+R, but heck ...

    This also solves ALL async debugging issues for me! And AsyncOperation scene issues prefiring to the new scene.

    Literally everything was major was resolved do to this ....... so it seems that if Unity improved the refresh to be more-smart instead of just refreshing for every small thing we do (and the full scope of the project for each refresh), we'd be looking dandy! I think some learning AI would be useful here to figure out if they should refresh or not, and what scope.

    But really, AI excluded, how about just give us a bunch of options in the meantime? Auto refresh is potentailly nice! It's just currently too much with too large of a scope. I don't want you to scan my entire project for changes while I'm debugging async (especially when I already checked "DONT RECOMPILE UNTIL STOPPED", yet does it anyway). I don't want it refreshing in the background when Unity isn't focused. I don't want it scanning scopes outside of the scene.

    We need a semi-auto refresh mode with options. This..... this changed my world. I get 20% of my day back! +40% when testing.

    and the main reason for issues at all (minus battery drains on laptops) is that refresh freezes all threads even when times it doesn't need to do so! I should be able to continue what I'm doing and simply block out the PLAY button.

    TL;DR: There needs to be *some* intelligence to this instead of just "freeze all threads and refresh the entire project, 100% of the scope, even in an empty scene" when alt tabbing between Discord and Unity with 0 changes.

    ----

    I used to bug report all the time until my project got over 20gb -- then I stopped after realizing QA doesn't even attempt to repro if no project is attached (even if detailed).

    However, now I have it down to 12gb: Can't spot these AsyncOperation scene jumping issues? My project will work wonders for repro. Repro'd 100% every time for the past 1.5 years (until I turned off refresh).

    I can submit my 12gb project if you'll have a look.

    ----

    As for text issues, I now use TextMeshPro: Ever since then, the only text issue I get is a similar one to the garbled text - it turns into robotic looking font until I press play and stop (or hide+show it).

    ----

    As for UI issues, ScrollRects still mess up BAD and collapse upon themselves and have major anchor issues all over the place, all the time. I can't hide/show them to fix like others: I must play then stop. THEN it resets. Super frustrating.

    Definitely doing this next - have any recommended guides? I saw a few, but not sure if they're dated.

    All IL2CPP errors are found @ the final step (after 99% of compilation waiting) among other errors that cause your build to stop -- it's always at the end, not before the bloaty stuff. I wish I remembered more specifics. I had an error that came up at the end a few weeks ago, but can't recall what it was about ... I wanna say something to do with scene order... or leaving a scene on that doesn't exist anymore.... or something like that.
     
    Last edited: Jun 13, 2019
  19. Ryanc_unity

    Ryanc_unity

    Unity Technologies

    Joined:
    Jul 22, 2015
    Posts:
    201
    IL2CPP, now that makes more sense. Though this is not possible to move forward in the build process as the code stripping process part of IL2CPP needs information about what content is used by your game. So this forces a build ordering of: Build player assemblies > Build player content > Build IL2CPP.

    Edit: If there are some common specific failure messages that you see and think they should appear earlier in the process, do let us know what they are and we can dig into those specific ones or that area of the build process and see what we can do to improve it.
     
    Last edited: Jun 13, 2019
  20. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    1,661
    As a starting point, split third party and your code into separate assemblies.
    Also, split your "libraries / frameworks" to the separate assembly as well.
    That will provide some instant time results without really breaking your code real hard.

    I do not think there's such thing as a guide for this. Because its very project dependent.
    Best advice - keep it simple, divide & conquer.

    I've also broke each root subfolder of scripts / systems into a separate assembly.
    But that took me almost a week just to decouple logic and fix dependency errors
    (for about ~2 years of my code hobby writing).

    Learned that interfaces and decoupling make wonders together.
    Also, that the data should be stored separately, and should not rely upon sub-systems.
    That will prevent circular dependency loop in most of the cases.

    Cons - some assets aren't really good at being partioned.
    Those that rely on strict path rules and had to be modified manually potentially preventing future updates.

    As well as those that like splitting each script into a separate editor folder (because their code has to be rebased under single editor assembly).

    And some assets aren't really possible to put into any of the assemblies, as they were build that way.
    (Unfortunately I had to leave them into default assembly).

    E.g. tools and such.

    In the end it was worth it. My code base became way better than it was before.
    Recompiling don't take as much time as it was before for me, so there's also that.

    Just make sure you've got a backup set (if you do want to do something radical as me).
     
    Last edited: Jun 13, 2019
  21. alexeyzakharov

    alexeyzakharov

    Unity Technologies

    Joined:
    Jul 2, 2014
    Posts:
    230
    Yes. We looked at what's happening during enterplaymode and came up with a long list of optimizations last year. Attributes lookup was one of the noticeable contributors to enterplaymode and general Editor performance that cripples the scalability. For 2019.2 we did optimize most of the usecases in the Editor and exposed a public api for use by plugins/packages -
    https://forum.unity.com/threads/uni...type-attributes-in-the-editor-tooling.687682/.
    If you see any usage in the Editor of attributes extraction that is still slow, please report it and we make it faster.