Search Unity

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

Discussion in 'Editor & General Support' started by MrLucid72, Jun 8, 2019.

  1. MrLucid72

    MrLucid72

    Joined:
    Jan 12, 2016
    Posts:
    988
    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

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,610
    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:
    657
    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:
    612
    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:
    395
    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 MrLucid72 like this.
  6. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    3,296
    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:
    69
    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:
    10,773
    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:
    201
    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:
    395
    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,555
    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

    Joined:
    Nov 23, 2012
    Posts:
    1,226
    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

    Administrator

    Joined:
    Jun 11, 2014
    Posts:
    461
    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:
    4,195
    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.
     
    Ruslank100 and Peter77 like this.
  15. Mads-Nyholm

    Mads-Nyholm

    Unity Technologies

    Joined:
    Aug 19, 2013
    Posts:
    217
    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:
    332
    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:
    1,188
    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. MrLucid72

    MrLucid72

    Joined:
    Jan 12, 2016
    Posts:
    988
    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:
    332
    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:
    3,296
    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

    Joined:
    Jul 2, 2014
    Posts:
    507
    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.
     
  22. MrLucid72

    MrLucid72

    Joined:
    Jan 12, 2016
    Posts:
    988
    @alexeyzakharov
    Thanks for the editor improvements in 2019.2! Looking forward to it :)

    What I have to do now (and have been significantly more happy since I did) is turn off auto refresh (workaround). Then I just CTRL+R refresh whenever necessary.

    However, I wouldn't have been confident to do this without working on Unity for years: And it's still only just a workaround.

    Any plans to implement some type of "smart refresh"? One of the biggest issues unanswered, yet, is editor recompiling on an unnecessary scope (combo'ing with many unnecessarily-timed triggers): That is, the entire project being scanned for changes instead of just local - and refreshed for every small thing you do (even alt tabbing back and forth - mentioned below). It feels like a "placeholder" feature for something yet to be implemented, as there's no way it's acceptable to scan/recompile 100% of the scope each time.

    I know you guys are aware of it since there were originally transparent plans to fix it that were silently abandoned - what was replaced - and when could we possibly expect it?

    * Let's say something is imported -- clearly the entire project doesn't need a recompile if I just add a png, since nothing is connected to it yet! Script? Sure -- maybe it has dependencies. But not *everything*.

    * Let's say I don't allow recompiling while playing and I don't change anything: I click play, then click stop. What does Unity do? Recompiles/scans entire project again. If I don't allow live changes and didn't change anything that would trigger Unity to be dirty, this seems like it isn't testing anything to decide -- it just "does".

    * When I alt+tab to a browser, then alt+tab back in, why does it scan the entire project for changes? Can't you detect it was just a focus move? I didn't drop anything in my project. No code was changed. Nothing at all -- and this is what also causes the infamous "prematurely fire to next async scene loaded bug (which combo bugs with the "can't debug ANYTHING in Visual Studio that's Async => resolved by turning off auto refresh. Seriously~)" because Unity doesn't like to scan for changes while an AsyncOp is going -- it messes up everything.

    * Async anything and auto refresh ^ messes up both Unity editor and VS.

    I swear if I just don't do anything and look at Unity too often, it'll refresh/scan/recompile /s

    But in all seriousness, this is a big issue that I haven't seen addressed, ignoring bigger projects that run into this issue (new-Unity experiences do not notice this because their project isn't big enough).
     
    Last edited: Jul 1, 2019
  23. John_Leorid

    John_Leorid

    Joined:
    Nov 5, 2012
    Posts:
    650
    Is there any way to manually handle garbage collection inside the editor?

    Scene View, Hierarchy and Inspector are running their GC during play Mode, which leads to lag as well as unity ignoring any (keyboard/mouse) inputs for ~10 seconds. Testing my First Person Shooter, especially the jumping puzzles is just impossible while any of the Editor Windows (inspector,..) is drawn. As a coder, I have to watch values in the inspector and I have 32GB of RAM, only up to 8GB are used by unity, so theres plenty of space to delay the GC for those Editor Windows until I exit play Mode.

    20-30 seconds of recompile time whenever I change a single comment in my code is one thing, another 20-30seconds to enter play Mode too, but GC causing heavy lags during testing (and also while navigating the scene when not in play mode) makes the editor basically Impossible to use.
    The Projekt has ~25GB total size, the scene I am talking about is just a test scene with less than 50 Individual objects, made out of unity's standard cubes and about 10 characters (low poly, default amount of human bones) + FPS player, no Model, 5 guns. total: less than 200 individual items in the hierarchy and very simple scripts in this specific case.
    But the lag happens in all scenes of this and another project. For contract work I have to work on an very old project, using Unity 5.3.6f1 - which is about 10GB and has no lag at all, despite lots of Code (TNet multiplayer, Gaia, ...)

    So it's not my computer and I doubt it's because of the projects because both use completely different assets and I lived with the lag for a long long time already, long before I installed any assets - working on 5.3.6f1 just showed me that it could be so much better.
     
    MrLucid72 likes this.
  24. shawnblais

    shawnblais

    Joined:
    Oct 11, 2012
    Posts:
    324
    Regarding ASMDEF's, I have tried many times to set them up, and never have I saved a single second of reload time. Each ASMDEF seems to have it's own overhead that easily negates (and usually exceeds)_ the compile time of the scripts themselves. Can you point to any examples of a project with 10,000 files, that allows you to recompile scripts in < 10 seconds? I've literally never seen this in the wild, and have tried many times to rig up entire projects with ASMDEF. It's quite easy to reach this file counts, with many asset packs having 2000+ files. It's generally a time sink to have to optimize these packs, and not ideal, as we want them in the project as a library of ready-to-go assets.

    I really think we're barking up the wrong tree here. ASMDEF's are slow hard to setup and maintain, and just not a realistic solution for production. Compile times in general are not that slow, it's domain reload that is the killer.

    What is slow, is this whole-project scan any time a script file changes. This has to be addressed.

    I think I have an elegant solution: Just allow us to mark /Plugins as "Manual Reload", and give us a "Reload Plugins" btn somewhere. Then we can just press a btn when we want a full project scan, if not, Plugins would be ignored (use my ssd to cache the whole thing, I don't care, storage costs pennies and I just need iteration speed).

    This would allow us to continue to iterate extremely quickly as the project scales, and it's a very simple, straight-forward no-fuss implementation.

    Please consider this.

    In production I will make about 100 script changes, for every time my /Plugins actually changes. Please let us optimize out the 99 scans of 10,000 files that does not need to be happening. Actual project files that change frequently tend to be < 500. /Plugins is very cold, /Scripts is hot, we need something to address that reality.
     
    Last edited: Sep 28, 2020
  25. MrLucid72

    MrLucid72

    Joined:
    Jan 12, 2016
    Posts:
    988
    Still applicable in 2021.

    A new example: TMPro Unicode bug reported in 2018. Years of follow-ups. Finally, it's fixed! ....only in 2020.1.16. They refused to backport it to even 2020.16.9, or the 2019 LTS, that was only 1 month to a year old. What's even the point of LTS or bug reporting if Unity ditched issuing patches for devastatingly-breaking issues? Chinese folks + chat boxes (IME bug) were [and still are] completely destroyed <2020.1.2.

    I must've spent 100 hours submitting bug reports, repros, screencasts, screenshots... and they only had 1 single QA assigned that took 3 years to complete, without a patch at all.

    The irony is that I tried the patch 2020.1.16 and it came with a breaking async bug: The entire point of this thread.

    The entire reason I didn't want to upgrade since Unity QA is non-existent. They're going to deny this exists since I didn't submit a repro (they don't like to pay for their own QA), but folks will soon find out the hard way when it's reported en masse later. For the record, I *did* report it - just not a repro. Let's wait and see what happens so we can "I told you so" and show nothing has changed this since this post.

    Disappointingly, years later, it appears that Unity is still more of a marketing company than a game engine, in terms of expectations to reality :( giant budget not spent on fixes/stability, but fluff features and marketing. Excellent new-user experience. Once you dive deep, good luck - you're on your own. Even if you have a "success advisor" (which I have - I pay monthly for a sub fee, and they don't do anything to assist with breaking issues; it's just another fluff feature listed. A success advisor simply apologizes to you twice instead of once then doesn't actually take action).

    Again, I post this out of love, despite the tone, much like a "tiger mom" seeing a smart kid that wastes his life on drugs and bad choices. It's such a potentially incredible engine... we have a live game with it. However, we would've been able to launch and maintain the game in 1/8 the time (and with 1/8th the hair ripped out by frustration) by simply having Unity put bugs/editor stability first like all other enterprise softwares do -- like Unreal does -- like everyone does except Unity's $200 mil 2020 revenue (+50% from 2019) that doesn't seem to actually go anywhere useful, but seemingly instead to bag-of-holding-sized investor pockets.
     
    Last edited: Jan 18, 2021
  26. MrLucid72

    MrLucid72

    Joined:
    Jan 12, 2016
    Posts:
    988
    Infinite/Ongoing/Untested Unity Hub Issues

    Reported long, long ago (since the first beta, even):

    * Production versions are killing off licenses
    * You cannot refresh your license or face infinite refresh time
    * Your license will falsely say it's invalid (even with copy paste)
    * Entering a new license will have vague errors such as "Failed to reach Unity license server" that don't go away until you reinstall
     
  27. pbritton

    pbritton

    Joined:
    Nov 14, 2016
    Posts:
    159
    Unfortunately these issues still linger almost 2 years after the original post. :(
     
    MrLucid72 likes this.
  28. dCalle

    dCalle

    Joined:
    Dec 16, 2013
    Posts:
    55
    thank god unreal engine 5 finally has an UI that doesn't give you eyecancer anymore . byebye alt-tab-10-seconds-wait