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.

Feedback Recompile + Enter Play Mode Process

Discussion in '2019.3 Beta' started by Seith, Nov 15, 2019.

  1. Seith

    Seith

    Joined:
    Nov 3, 2012
    Posts:
    755
    Hi Unity devs, (@alexeyzakharov @Justinasg)

    Since I moved from 2019.1.5 my workflow has really taken a hit, due to something that might sound insignificant to you but that's had a non-negligible impact for me (projects like Ghost of a Tale tend to be rather large).

    The issue in the 2019.3 beta10 is that as soon as I modify a script and then go back to the editor for a recompile, the editor becomes completely frozen (unresponsive) right away. In 2019.1 there was a two seconds window during which the recompile process started but you could still click on the play button. So in effect you were able to daisy-chain recompilation + enter play mode in one single click.

    But now with the editor getting frozen right away I have to wait for 15s for the recompile process to finish in order to be able to then click on the play button and wait another 10s before entering play mode. That is super disruptive (as of course happens hundreds of times per day).

    Is there a chance you guys could have a look into this please?
     
    WermHat, stonstad, Seb-1814 and 5 others like this.
  2. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    461
    I think this might because of the asset import changes that happened in 2019.3 and that the import and compilation of a script happens earlier than before and when you switch to the editor, we are already reloading the assemblies and this process locks the editor.

    I would say that the previous behavior was not intended and I don't think we will bring it back.

    I would recommend that you instead implement this behavior yourself and automate it.

    You should be able to do this by 1) hooking into when compilation finishes.

    https://docs.unity3d.com/ScriptReference/Compilation.CompilationPipeline-compilationFinished.html

    2) And then set EditorApplication.isPlaying to true in that callback to enter play mode afterwards.

    https://docs.unity3d.com/ScriptReference/EditorApplication-isPlaying.html

    You could implement this as optional behavior by using a checked menu item that you can toggle on or off.

    https://docs.unity3d.com/ScriptReference/Menu.GetChecked.html
     
    idbrii likes this.
  3. rastlin

    rastlin

    Joined:
    Jun 5, 2017
    Posts:
    127
    @lukaszunity How about Unity finally implements a responsive UI, so our entire editor is not frozen when it's doing some background tasks :) ? Proper approach to those use cases would be to display a tooltip "compiling..." while still allowing us to use the editor using the old compiled sources and refresh it when it's done.

    Take a look at VS 2019, it launches much faster those days, while finalizing some background tasks as you start working with the solution.

    This way Seith could still click Play button even while compilation is in progress and it will wait untill the process is done before triggering play mode.
     
  4. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    461
    When assemblies are reloaded, we actually unload ALL C# code, even the editor UI code and there is a point in time where no C# code is loaded. We then load the new C# assemblies and restore all their state and invoke all the MonoBehaviour.Awake, InitializeOnLoad, etc. callbacks. So there has to be some blocking operation to be able to reload code due how Unity is designed around the main thread.

    If you are experiencing long reload times, I recommend using the Profiler and enabling Editor profiling and then look through the data after are the assembly reload and find the very long frame and drill down into the profiling data. We often see long reload times because projects contain C# or third party code/plugins that spends a long time initializing after reload.
     
    Last edited: Nov 15, 2019
  5. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,076
    Being able to tab back to the editor and press play before compilation was finished is one of the few things that makes programming for Unity at all bearable. Whenever there's a pause that's longer than 5+, it's very easy to get distracted and check email or forums or whatever, so the 5+ second pause becomes a 5 minute one. This change makes it so that we have two of those 5+ second delays instead of one. Every_single_time we make a code change.

    If you break this, you've made a net negative impact on editor usability in the 2019 cycle. So please don't.


    You're creating all of these features around entering play mode and whatnot that's supposed to improve the experience, but then you just keep making it worse by breaking stuff like this.

    It feels like understanding the usability of the editor isn't a priority at all for you, and that's really frustrating.
     
    kreso, WermHat, dginovker and 8 others like this.
  6. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    461
    I think this is a fair point. I'm just saying that this behavior wasn't intended and I'm not saying that the new behavior is better, but that we probably won't bring back unintended behavior.

    I think we should rather add explicit support for this workflow, maybe with an option like "Enter play mode after successful compile", so you only get 1 assembly reload instead of 2.

    Let me know what your thoughts are on explicitly supporting this in the editor in way that would be better than just delaying asset import and script compilation "for a bit". :)
     
  7. M_R

    M_R

    Joined:
    Apr 15, 2015
    Posts:
    556
    for me it is an improvement. in the old version, I either:
    - pressed play while compiling, not get feedback, press play again, then when domain reloaded it immediately exited play mode
    - or if Unity managed to enter play mode and then reload the assembly, I needed to stop and then re-enter play mode because either our code or some 3rd party plugin I have breaks (because of singleton abuse and init non serializable state in Awake())

    now at least Unity is already reloading when I focus.
    an improvement could be to make the play button still responsive even when reloading (write that part of UI in c+?)
    (ideally I'd like partial reload of only the recompiled assemblies and dependencies, but that is on Mono to support first)

    or: add ability to only load some of the assemblies for a given editor session (like on-demand import of assets)
     
  8. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,076
    That wouldn't help much, as it's horrible for editing editor scripts. I don't want to enter play mode when I just made an edit to a ScriptableObject's Editor, or something like that. I don't usually work exclusively with editor scripts or exclusively with gameplay scripts. Instead, I work with both in tandem, so I generally want to enter playmode after switching to Unity about every other time.

    There's essentially two things I want to be preserved:
    - I should be able to alt+tab to the editor, and have it recompile, reload assemblies, and enter play mode as soon as possible. This is ideal when editing gameplay scripts.
    I should be able to alt+tab to the editor, and have it recompile, reload assemblies, and not enter playmode. This is ideal when editing editor scripts.

    The current (old) implementation manages to do both fine, because there's a window after I alt+tab where I can press ctrl+p to activate the play mode button, which is blocked from entering play mode until recompilation and assembly reload is finished. That that wasn't intended doesn't mean that it's not good.


    The community has been asking you to get the main Unity Editor window and the play button off the main thread since forever, though that's usually asked for so there's a way to break out of infinite loops without killing the editor. This might be the time to actually do that.
     
    daRedLoCo, cxode, jdtec and 2 others like this.
  9. laessnb

    laessnb

    Joined:
    Jun 10, 2014
    Posts:
    98
    I agree that this is a frustrating change. I don't want to auto-play every time I tab back in. Maybe have the blocking "compiling scripts" pop-up include a Steam-style "play when done" button that we can click, as a way to emulate the old behavior of being able to click Play during those couple of seconds before the whole editor hangs?
     
  10. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,289
    What about background importing on another tread?
    So the editor does not get blocked during import.
     
  11. DoctorShinobi

    DoctorShinobi

    Joined:
    Oct 5, 2012
    Posts:
    216
    One workaround might be to use Visual Studio's "Attach to unity and play" debug configuration:
    upload_2019-11-16_0-30-57.png

    It's not ideal to enter debug mode, but at least until there's a better solution you can enter play mode right after compiling
     
  12. konsic

    konsic

    Joined:
    Oct 19, 2015
    Posts:
    995
    Where is Attach to unity and play located?
     
  13. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    700
    The only way I see to get rid of the long pause in the recompilation is to get rid of AppDomain Reload completely.
    A single line of change in the source code in a tiny assembly will trigger AppDomain Reload and it will completely reload all the assemblies. Pretty crazy, right?
    There is no way to get around in the current system.
    The good news is that .Net Core can manage assemblies in finer granularity and it can just reload only the changed assemblies. Imagine less than a second compilation including reloading.

    We should push Unity to move to .Net Core as soon as possible. That's when we can call it Unity updated for the 21st century.
     
  14. SugoiDev

    SugoiDev

    Joined:
    Mar 27, 2013
    Posts:
    395
    There was a prototype to port Unity to .NET Core, but only a prototype: https://xoofx.com/blog/2018/04/06/porting-unity-to-coreclr/

    It should be possible, but the efforts aren't to be taken lightly.

    I would love to see assembly load context in Unity. It really would end all this AppDomain reload insanity.
    But again, porting something this old and large isn't cheap.
    I'm not sure we'll ever see it land.
     
    andreyefimov2010 likes this.
  15. DoctorShinobi

    DoctorShinobi

    Joined:
    Oct 5, 2012
    Posts:
    216
    It's in this drop down menu:
    upload_2019-11-16_3-31-33.png

    I'm using Visual Studio 2019 with the Unity plugin.
     
    konsic likes this.
  16. hatless

    hatless

    Joined:
    Dec 15, 2010
    Posts:
    48
    Not to put too fine a point on it, but why does unity sit in the background doing nothing when you save changes to the code, and then grab the interface away from you the moment you alt-tab back? That's almost willfully rude.
     
  17. laessnb

    laessnb

    Joined:
    Jun 10, 2014
    Posts:
    98
    With Visual Studio 2019, by default it actually compiles as soon as you hit save... and I absolutely can't stand it. It was constantly spinning up compilation and recompilation and re-recompilation while I was trying to get work done in VS, so I disabled it. Not to mention Unity occasionally crashing out from under me while I was making changes to script files in VS.
     
    cxode and jdtec like this.
  18. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    461
    I did a quick debug session of the new asset import code and I can now confirm that we block the main thread after importing a script and wait script compilation to finish in the same frame because "Auto Refresh" is hard coded to be a synchronous import. This explains why you do not have the window of time to enter play mode, because there are no editor updates/redraw frames between import and reloading assemblies.

    I also tested it with "Auto Refresh" disabled in preferences and then using Cmd+R/Ctrl+R to refresh manually and it looks like we do perform an asynchronous import in that case, e.g. the old behavior. And it appears that the workflow with entering play mode before script compilation finishes works with a manual refresh. It would be great if the people who are experiencing this issue could confirm this.

    Based upon the feedback in this thread, I would consider the synchronous import with "Auto Refresh" enabled a bug and regression and I would encourage you to report a bug on it and then vote on the issue in the public issue tracker once it has been proceed by QA. The more votes an issue gets, the more visibility it will get internally :)

    I have raised your this issue with the asset pipeline team internally and asked them respond to this thread as soon as possible.

    I have also let UX know of this workflow and asked them have a look at a better workflow for this that isn't based upon timing and how fast scripts compile. Because we could in theory compile scripts faster in the future and we would be back to the same issue again where isn't enough time to click the play mode button.

    One suggestion I have besides disabling "Auto Refresh", is that we in Preferences have we the "Script Changes While Playing" option and we could add a new mode called something like "Stop Playing And Recompile, start playing". Which would exit play mode, recompile scripts and enter play mode again (if you have 0 compile errors) when a script changes. This would allow you to control the behavior by keeping the editor in play mode when you want to iterate on game code and being outside of play mode when you want to iterate on editor code. The downside is that it wouldn't work if you have compile errors after giving the editor focus. Let me know what you think :)
     
    Last edited: Nov 16, 2019
  19. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,326
    It sounds like a good short-term workaround for me. I had actually implemented this myself in older Unity versions :)
     
    cxode, SugoiDev and Lars-Steenhoff like this.
  20. Seith

    Seith

    Joined:
    Nov 3, 2012
    Posts:
    755
    Alright. I'm warning you, this is going to be a rant. And an open letter to the developers of Unity.

    That thing I brought up in the opening post is merely a symptom.

    The problem is that almost none of you guys are working on very large AA or AAA games using your own engine (Unity). That is the crux of the issue.

    And I'm not talking about making impressive demos, which are basically cinematic sequences destined to prove to the world that Unity can do amazing graphics. You know what? You've already proven this a couple of years ago.

    What you have NOT yet proven, however, is that Unity is designed for top-notch development of rather large and demanding games (and yes I'm including Ghost of a Tale in this).

    What you're missing is the deep seamless experience that a game is expected to be nowadays. It's not just about the visuals (I can't believe I'm saying that) on a 50m by 50m with baked static effects that can have no real application in an actual interactive production where the camera could be anywhere at any time.

    If you guys had to live through the actual realities that teams like ours are living through on a daily basis you would go "wait that's crazy we should address that". We have to wait almost thirty seconds every time we need to make a small code change and test it in-game. Now multiply this by a hundred times or more during the day.

    The Unreal Engine can enter game mode almost instantly. But you know what it doesn't have? The elegance and ease of use of Unity. The Unreal Engine is a work horse that's designed from the ground up to be a powerful game engine. Unity is much more user-friendly but it's also trying to be many things to many people.

    When you guys make demos on stages around the world or show off the engine to students, the issues of inefficiency and time-wasting are never broached because on such a small level they almost don't register. But do you want Unity to keep being considered an entry-level engine in the game industry because of this? By all means if you're satisfied with that state of things then fine, I'm the fool for not understanding that sooner.

    I want to keep using Unity. But you guys need to take the needs of producing larger games into account. All of your users will eventually benefit from it.

    Now Lukasz, I thank you for your reply. But there should not have to be a "voting" on that issue. This is not a matter of opinion and even less a popularity contest. Please, do bring this up to your management and hopefully they'll realize a fundamental shift in priorities needs to happen at some point.
     
    kreso, Quasar47, horatiu665 and 38 others like this.
  21. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    700
    Very well said Seith, I can't agree more with you.

    Unity should stop making eye-candies for every event. We've all seen it and I believe it's very capable. Seeing it more doesn't make me excited and perceived as an excuse to show something by pressure.

    What about making an AAA game? Does Unity scale up? Hell no. It's an on-going battle fighting the sluggish Editor every day.

    Yeah, Unity has employees who had experiences working on AAA titles but did they use Unity to make it? If not, it doesn't really matter.

    So, stop mucking around eye-candies. Yeah, it's important but what's more important is the core. The core of Unity is to make a game, not eye-candies. And It must scaleup with as efficiently as possible.

    Enough said, and you should make a slogan "Performance by Default for the Editor!" It benefits everyone immediately and I rather have a performant editor that I use everyday first than DOTS.

    Kill some projects if you have to and move to .Net Core as soon as possible to get rid of the crazy AppDomain Reload. I don't see any better way.
     
    Last edited: Nov 17, 2019
  22. konsic

    konsic

    Joined:
    Oct 19, 2015
    Posts:
    995
    Please can we get this in 2019.3 release?
     
  23. Ramobo

    Ramobo

    Joined:
    Dec 26, 2018
    Posts:
    212
    What? .NET Core? Editor Performance by Default? Basically anything? Considering Unity's track record, it's going to take a few years at the very least.
     
  24. konsic

    konsic

    Joined:
    Oct 19, 2015
    Posts:
    995
    Editor performance and immediate entrance to play mode
     
  25. Ramobo

    Ramobo

    Joined:
    Dec 26, 2018
    Posts:
    212
    Yeah, considering Unity's track record, it will take a while. Right now, the closest you're getting to that is throwing static variables out the window (preferred option, can also use an ugly reset method) and using 2019.3's experimental enter play mode options.

    Before someone asks for examples of Unity's track record: nested prefabs (2018.3), updated .NET (experimental in 2017.1, released in 2018.1), free dark theme ("news on that in 2020")...
     
  26. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    700
    Yeah, time in Unity goes about 2 or 3 times slower and it may take a while but we have to keep asking.
    My goal right now is to put .Net Core port on the Roadmap.
    If you fart long enough, S*** will finally come out.
     
  27. rastlin

    rastlin

    Joined:
    Jun 5, 2017
    Posts:
    127
    May I ask why do you need .Net Core in Unity?
     
  28. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    700
    Right now to change a single dll, you will have to unload everything and then load everything using AppDomain system.
    The compilation itself can take less a second for a simple assembly but reloading every assembly again can take up to 10s of seconds. Pretty dumb, right?

    But .Net Core allows you to manage individual dlls. (AssemblyLoadContext). It will allow you to swap just the changed dll pretty much instantly. And it will also be possible to hot-swap dlls during runtime. This is a holy-grail of fast development.

    I'm not the only one who is excited.
    https://www.strathweb.com/2019/01/collectible-assemblies-in-net-core-3-0/

    Also .Net Core runtime is really fast. I saw some reports that .Net Core is as fast as having Burst compiler. That's without us doing anything special.

    So what's keeping us from using .Net Core? Only Unity can answer.
     
    Andresmonte, idbrii, Ramobo and 2 others like this.
  29. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    461
    Thank you for taking the time to provide detailed feedback.

    I'm suggesting to create a bug and vote on it to surface it among all the other issues that reported and for it to show up on various dashboards within in the company as a critical issue. This isn't about opinion nor popularity, but using the tools at your disposal to make changes happen.

    I will share this feedback with management within the company.

    Migrating to .NET Core is non-trivial due to how tightly Unity integrates with it's .NET runtimes (Mono/IL2CPP) and how much code there is Unity that uses .NET runtime from C++. Unity does not run on top of the .NET runtimes, but uses it as a third party native library, similar to how we use physics, etc. native libraries. So isn't just a matter of switching it to .NET Core and recompiling all the code. We do various tricks with the GC, managed memory, etc. from C++ to get the best possible performance and these tricks do not translate directly to .NET Core, because it is implemented and behaves very differently from Mono/ILCPP. Also note that moving to .NET Core will be a breaking change, as there are System APIs in .NET Framework that are not available in .NET Core.

    The prototype effort by Alex Mutel (who still works at Unity) showed promise and we are still exploring the possibility of migrating to .NET Core with the minimum amount of breakage, but in the end there will be some breakage due to .NET Core design choices, such as dropping APIs.
     
  30. DoctorShinobi

    DoctorShinobi

    Joined:
    Oct 5, 2012
    Posts:
    216
    Where did you hear that?
     
  31. willgoldstone

    willgoldstone

    Unity Technologies

    Joined:
    Oct 2, 2006
    Posts:
    791
    Hello! Just wanted to chime in here as I did a little on twitter where you quoted this, I replied a bit there so some of this will be copy paste, bear with! but hey - I can actually write without [...] here so yay.

    Ok so where to start. Well, for the first part - You're echo'ing a sentiment we discuss internally a lot - and something that we've been working on addressing for about 3 years now. When you hear us talk about DOTS, rewriting core systems, architecture and workflow - its because of what you describe. We started out with no separation between authoring and runtime data formats, which really does not scale - and so DOTS is our answer to that. The workflow stuff i'm doing with teams in CPH and Montreal is what builds on top of that to keep the user-friendly Unity you're describing. Super smart people like @NikolineUX and @KjartanKennedy are laser focused on this with a team of amazing engineers. We also have large productions in the works (not demos) where we are feeling the real pain directly and tackling it head on. It's bringing about real change that we've not delivered soon enough and for that - I'm sorry for the stress you and others have dealt with. I'm super excited about what we're shipping over the next few releases, starting with the new asset database in 2019.3 and on-demand import in 20.1 which really make a big difference. These big changes are critical & for people like yourself who have developed in the 17.x, 18.x versions, it will hopefully feel worlds apart.

    Next is the vision for Unity going forward - we plan to execute our vision for Performance with a 'no person left behind' approach. This is why we're working on the 'Conversion workflow' for Game Objects, and why we're working hard to create simpler forms of performant ECS coding. Conversion converts GOs directly to Entities - the data format which can easily be processed by the Burst compiler, multithreaded etc. This is something we want to obfuscate from the user - just improve performance behind the scenes, but also give deep profiling tools that allow you to understand and process (mentally I mean!) what is happening in the runtime format. We know the critical nature of retaining the aspects of Unity people love, whilst destroying what they hate - the lags, the waiting, the bottlenecks, the scale issues, the ambiguity - we're doing what we call Production Engineering nowadays to be super on-this. It means we're building a large production which is forcing us to really crush all of the problems you and others have been telling us about for a long time. It's taken a lot of research, some harsh realisations and some great hires to get us to where we are now, but I believe we're on a great path - and i'm not just saying that to sell you on it, as you know I've been here a long time (9 years!) and used Unity for 11 years, so I've seen the good and the bad.

    Let's keep talking - its all of our responsibility here to make what i'm alluding to here a reality, and we need your help to keep that dream in check and make it happen. Thanks for all you and others in this thread (Hi Baste!) have been doing to help us, you rock.
     
  32. Ramobo

    Ramobo

    Joined:
    Dec 26, 2018
    Posts:
    212
    DoctorShinobi likes this.
  33. Ramobo

    Ramobo

    Joined:
    Dec 26, 2018
    Posts:
    212
    What Unity seems to be missing with DOTS is that it's a whole new paradigm and some people just want an updated and cleaner (avoid reflection, use override/interfaces instead...) MonoBehaviour (some ASAP). Write the whole engine in DOTS for all I care, but show MonoBehaviour some love too. No, this isn't a "MonoBehaviour removal?" panic post. What happened to "ScriptBehaviour"? Did it get moved to the rock bottom of their backlog like auto property serialization basically was?
     
    Last edited: Nov 20, 2019
    Seith likes this.
  34. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,076
    Hi!

    One of the things causing a bit of a disconnect here is that all of the things you're talking about is new stuff. It's a lot of "hey, we need to rebuild all of the core systems so things can go fast!". What we're saying is that editing in Unity the way it is now - ie. with no DOTS - was faster, back in the Unity 4 days. There's a real sentiment that you have regressed, especially in regards to how the editor itself performs.

    Look at this test by the wonderful @Peter77. In the latest versions of Unity, the base overhead cost of entering play mode in an empty game is 2x what it was in Unity 4. That means that there's been a buildup of cruft that we as Unity users can do nothing about that's costing us a bunch of time.

    And no amount of DOTS can help, since there's no way the conversion workflow or other optimizations on how we do things are going to be faster than not having anything in the scene at all. Which means that you might be barking up the wrong tree.


    In other words, it feels like you're only pursuing big, interesting ways of making the engine faster, instead of doing the boring work of fixing all of the thousand tiny little inefficiencies that you've introduced over the last five years.
     
    kreso, Quasar47, reinfeldx and 15 others like this.
  35. tatoforever

    tatoforever

    Joined:
    Apr 16, 2009
    Posts:
    4,285
    This might seems crazy but I think Unity should just start from scratch a new Engine like Epic did and keep supporting current ones with performance & bug fixes. Upgrading this old behemoth mammoth and making sure every projects is compatible with the latest features of Unity is a heck of a job and takes tremendous amount of time. Hence the reason why many features in Unity are buggy or takes ages to mature or even get fully implemented. Trying to be everything for everyone just slow downs everybody and is quite painful. At some point you have to fragment your userbase with different kind of software, tools and services like Autodesk and Adobe do.
    They should create a large scale game with and adapt the editor & engine to it.
     
  36. Seith

    Seith

    Joined:
    Nov 3, 2012
    Posts:
    755
    Again, thank you for this information, Will.

    What worries me most about this is the time it's going to take to get all of what you mentioned into a production-ready state. I understand Unity is more or less undergoing a structural change at the moment and I do not foresee all of this to be stable and usable before at least a year. More likely two (more if there are serious hurdles on the way).

    I know you guys are doing everything you can of course. And I suppose the real question for some of us users is going to be "Can we wrap our development calendar around Unity's"...
     
    Metron and konsic like this.
  37. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    319
    Hi everyone,

    I want to build on what @willgoldstone said and also address some of the concerns you're sharing about performance improvements availability.

    So like Will said, we're working with internal productions, but we're also collaborating closely with some enterprise customers, in order to better identify and solve issues related to scalability. This is work we're doing now, in the current editor, with the current tech stack. There is no systemic solution, this is not something DOTS can solve, it's about reporting and fixing all those 1000 paper cuts one at a time. This includes a lot of different things like large selection optimization, reducing unnecessary repaints, improving search speed, better caching, UX improvements, etc…

    There is a lot of moving pieces in the editor and new features are being constantly developed or improved, and we don't want to get in that same situation again. What we're also developing is better tools to monitor, identify and report performance issues, in context, from the editor. This will make it much easier for you to send performance regressions that includes actionable information, in order for us to tackle them promptly and efficiently.

    Most of that work should land in 2020.1, with a lot of them back-ported to 2019.4. We haven't solve everything yet, but we're actively working at making Unity a much smoother and enjoyable experience for everyone. Please keep reporting issues, thanks a lot for being patient, we're hearing you and taking action.

    Cheers,
     
  38. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    700
    @lukaszunity, Yeah, moving to .Net Core will involve quite a bit of change, however despite of the excuses, I don't see a future Unity with Mono. You know you will have to move to .Net Core in order to escape from the AppDomain reload hell. There is no other way around. If you don't want to do that, on other options is to rewrite AppDomain reload yourself. You have the full source and it might be easier for the interim solution.

    Instead of making the effort by a single person pet project, Unity should invest a lot more time and effort moving as soon as possible. I mean a lot more time. Until you make the commitment on the Roadmap, I don't see it it will happen.

    Perhaps build Unity V2 might be a better idea to leave all the baggages behind.

    I think adding new tech stacks on top of decades-old technologies will be increasingly difficult and we are all suffering ever getting slower editor. It was ok in early 2000 but not anymore.
     
  39. Seb-1814

    Seb-1814

    Joined:
    Nov 23, 2013
    Posts:
    22
    About the problem raised by the OP, I honestly cannot comprehend how this is not taken as a major issue. We are not talking about minor inconvenience that developers can work with until it eventually gets fixed, we are talking about a truly hostile ux. Please don't ask us to file an issue and go vote for it on the issue tracker, I personally find that almost offensive for an issue like that.
    I wish the unity engineers working on the feature (asset pipeline v2) had a better idea of the day to day experience of developers using unity with medium to big projects; surely the issue would have been caught sooner.
     
  40. chantey

    chantey

    Joined:
    Mar 5, 2017
    Posts:
    49
    yes please! :)
     
  41. hatless

    hatless

    Joined:
    Dec 15, 2010
    Posts:
    48
    You have badly misunderstood this thread.

    People are asking for less technology churn and more attention paid to moment-to-moment use, and you replied with this fulsome promise that Unity will be techier and churnier than ever before once the bold futuristic vision is finalized eighteen months from now.

    You read requests for less of a thing, and responded by swearing to double down on that thing.

    Let's start reading.
     
    andreyefimov2010 likes this.
  42. dthurn

    dthurn

    Joined:
    Feb 17, 2015
    Posts:
    75
    Sorry, is there a "click here to upvote this issue" link? This is a huge usability regression.
     
    cxode and jdtec like this.
  43. filod

    filod

    Joined:
    Oct 3, 2015
    Posts:
    175
    how about HDRP package? a Blank HDRP project takes about 10s+ to reload, so, should i consider HDRP as "third party code " and remove it ? since DOTS only support HDRP, so, should i remove DOTS either ?

    why not fire an Migrating to .NET issue and let's vote? i definely use up my votes on that.
     
    nimda32 and Andresmonte like this.
  44. petey

    petey

    Joined:
    May 20, 2009
    Posts:
    1,716
    Hey, just finding that having to wait for the compile to press play is actually having a big effect on my productivity. It may not sound like much but it's another step that you have to nurse along multiplied by the amount of times you do it in a day. It's draining watching the spinning compile icon all day.

    Did anyone come up with a workable solution?
    I'm using VSCode, I have the Unity plugin but I haven't found the "Attach to unity and play" option there. Does that exist in that editor?

    Also if it's easy to make a script that plays after compilation, could you consider making an example script? I've been trying but I can't get anything working.
     
    Last edited: Feb 6, 2020
  45. laessnb

    laessnb

    Joined:
    Jun 10, 2014
    Posts:
    98
    Unfortunately, so far the only workable solution I've found for this and other 2019.3 issues is to stay with 2019.2 for as long as possible.
     
  46. hertz-rat

    hertz-rat

    Joined:
    Nov 3, 2019
    Posts:
    71
    Just to chime in about HDRP (2019.3) enter-playmode times:

    Between saving a 1-line change to a c# file and being able to interact with my scene in play mode is timing out at 33s for me. If I don't modify any c# files, its 18-25s, usually about 22s. My project is only 3k LOC so I'm getting a little (edit: more than a little) apprehensive about what this will look like 6 months from now. It really, really adds up over the course of a day.
     
  47. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,076
    Has anyone that's experienced a severe regression from 2019.2 to 2019.3 actually sent a bug report with a repro project? Otherwise it will probably not get fixed.
     
  48. laessnb

    laessnb

    Joined:
    Jun 10, 2014
    Posts:
    98
    Obviously when possible, but a lot of these usability and functionality regressions are teetering into "By Design" territory, such as the editor reskin or the "fix" to prevent being able to press the Play button immediately after tabbing back into the editor before script compilation kicks off.
     
  49. killakiwi

    killakiwi

    Joined:
    Sep 5, 2013
    Posts:
    21
    How about having some code in a separate thread and listens for the CTRL P input, then triggers the Play button when compilation is done?
    This would fit on top of whatever future compilation improvements you guys make (DOTS etc) so it wouldn't be wasted work. Even if you reduce the compilation time, a dev workflow is typically to save code changers, alt tab, smash ctrl p or play in very quick succession, so there is no guarantee you will ever get compilation fast enough for this. Having a separate thread queue the action up solves the issue no matter the result of the speed improvements.
    It's been said many times but this simple thing really does degrade the Unity dev experience.
     
  50. cxode

    cxode

    Joined:
    Jun 7, 2017
    Posts:
    260
    Has anyone figured out, or made, a solution yet? This regression continues to drive me crazy.