Search Unity

  1. Unity 2019.1 is now released.
    Dismiss Notice

How about "Performance by Default" for Editor

Discussion in 'Editor Workflows' started by chrisk, Dec 19, 2018.

  1. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    Hi, guys,

    I'm working on a PC project that is relatively large and my experiences with UnityEditor is that it's so slow and it's becoming unbearable as it's getting bigger each day.

    I'm trying to understand why it's slow so that I can figure out what to do about it. If it cannot be fixed, I probably have to quit the job since the project is committed to Unity for now.

    1. Starting Editor with my project takes about 3 min. When loaded, it uses about 3GB Ram. The project size is about 50GB, therefore it's not trying to load the entire project into the memory. If so, why does it take so long to load? UnityEditor crashes quite often and it seems to slow down as I use, thus I need to restart the editor every once in a while and it's getting really annoying. I wouldn't care about the loading time as much if it doesn't crash that often and doesn't slow down over time.

    2. Press "Play" takes about 15 seconds to go into play mode with a simple test scene with 100s of GameObejcts. What is it trying to do? And there is no message.

    3. Saving a simple scene with 100s of GameObjects takes about 3 minutes and the editor is unresponsive. Again there is no message. I described the problem with saving a scene here in more details. I have pretty highend spec machine and I assure you it's not my system.
    https://forum.unity.com/threads/perforce-plugin-so-slow.600460/

    3. Quitting UnityEditor takes about a couple of minutes. Again, no message. What is it trying to do?

    I come from Unreal, and most of the task is much quicker. "Play" is almost instant and starting the Editor and asset imports are much quicker.

    I like Unity because of the faster compile time(compare to UE) but it looses all of its advantages in many other areas and it leaves a very bad impression and I'm starting to regret that I gave it a try but the project is committed to Unity and I'm very unhappy state at this moment.

    Unity is pushing "Performance by Default" slogan lately quite a lot. It's all good but it should start with the Editor first where we spend many many hours!!!

    I appreciate if someone can help me understand what's going on.

    Cheers!
     
  2. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    13,749
    All three of these seem extreme to me. One of the projects I'm working on is currently 10GB and while it isn't loading instantly it's definitely within the range of 15 seconds in 2018.2.15. What's your hardware configuration?

    Compiling scripts, serializing data into game objects, etc. For the same project mentioned above the time to start playing is within five seconds on my system (AMD Ryzen 5 1600X, 16GB DDR4-2666, 1TB SATA SSD).
     
  3. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    I have Ryzen 2700X, 32GB RAM, SSD(Editor and Projects are loaded from it), and using Perforce for the source control. For saving a scene, Perforce might have some affect but not in other cases.

    When you click "Play" does it always try to compile the script even if it's compiled already? And I can't imaging serializing will take that long for a simple scene.

    Perhaps Unity is not really made for large size project.

    Thanks for your help.
     
  4. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    A couple of experiments,

    1. Create an Empty Scene in my project and click "Play" takes about ~7 seconds.
    2. Create an Empty Scene in a new project and click "Play" take about a couple of seconds.

    It's so bizarre and I'm really dumbfounded about the result.
    What is Unity trying to do here?

    Can "Performance by Default" do a magic here?
     
  5. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    Here is the profile data of an Empty Scene in my project explaining why it takes more than ~7 seconds to start. It's obvious now why it takes that long but it doesn't make any sense to me.

    upload_2018-12-19_19-8-55.png

    First of all, why is it trying to reload Assemblies every time? Shouldn't assembly be loaded once unless it is changed, like when they are compiled? It doesn't make sense to load them everytime it "Plays" even when nothing changed.

    Second of all, why are all the assemblies loaded from the Empty Scene? It is so dumb to load all of them in the project regardless it's referenced or not.

    There is a big flaw in the engine I can't believe it left it this way for many years without fixing it. Unity really needs to eat their own dogfood, otherwise it's impossible it's left it this way for years and years. They've been all working on simple samples and saving few miliseconds doesn't make much difference but when it's close to 10seconds, they probably have done something about it long time ago.

    I think Unity should fix this to save countless hours from users before they do promote anything about "Performance by Default" It's is definitely considered as a critical bug. I'll not back down unless it's fixed. It's like Unity is eating our lives away.
     
    Xblade-Imperium42 likes this.
  6. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    3,833
    Note, didn't read the OP, no time, but I did look at the screenshot you just poster.

    Those are static constructors. Looks like you have something like:

    Code (csharp):
    1. [InitializeOnLoad]
    2. public class GaiaScriptOrderManager : ??? {
    3.  
    4.     static GaiaScriptOrderManager() {
    5.         // this takes 1 second to run
    6.     }
    7. }
    Since it runs 106 times, I assume that you have 106 classes marked with [InitializeOnLoad]. I might be wrong? That seems like a lot. Anyways, it takes 4 seconds to run their constructors, and Unity seems to be adding an additional second overhead to processing those.


    Unity's generally waaaay to slow to start up, but at least a part of that is you telling it to initialize a bunch of things on load.
     
    hippocoder likes this.
  7. castor76

    castor76

    Joined:
    Dec 5, 2011
    Posts:
    1,387
    Hi first of all. Welcome to the world of Unity. Where hair pulling experience becomes normal part of your life.

    I just feel like unity is not made for that kind of big project. At least not without a lot of ahead work to organize your data more efficiently.

    Having said that ... I think the reason why the assemblies are reloaded every time is to have a copy of it in the memory so that any changes you do in the play mode is not perm saved. So when you stop playing it restores the state of almost everything back to what it was before playing. Except some stuffs like shared assets such as shared materials or shard mesh etc..

    I know... been using Unity for since very early days and the fundamentally it has not changed but just kept adding stuff on the top. Unity now has more stuff going around than how it was in the beginning so it is obvious now that the editor stuff is not able to handle the amount of data that the user wants to use it for. That is probably why they are shifting towards using ECS and remaking the editor.

    I mean.. take a look at the videos in the youtube about how to make performance game in unity by some pronounced developers .. such as Inside developer etc.. they talk about using Unity as if best way to do things is Not using Unity like Unity. Most of these developer talks about seperating data from Unity itself and custom load them once tha game starts. Even the game logics are run on their own thread in their own engine. And only uses Unity for rendering purposes...

    I know. I know.. you may say then whats the point? Right.. I wonder about that everyday too. Just know that Unity is easy to get in but hard to get out kind of stuff.. and that is true for the making of the game as well. It is very easy to get into it.. but it becomes increasing difficult to do really cool stuff and bigger stuff as you do it. It is kinda give a false impression that you will be able to finish your game without much issues quickly in the beginning. But when you try and polish your game for performance and stability.. it becomes increasingly difficult. I feel like Unreal is somewhat otherway around. It presents itself with a lot of stuff so you have to learn it a lot longer than Unity but it sort of stays like that till the end.

    I also think it has to do with its business model. Where Unity needs more subscribers not necessary a successful games that gives them royalty. It is more like autodesk to me... on the other hand Unreal has other income resources from their games and they need royalty from the games so their approach can't be the same.

    I am not going to spark a engine war here. But just want to warp it up by saying that if you are stuck in Unity. Then the best thing to do is to try and learn its weakness and work around it. Now you have felt its weakness so it is up to you now.

    Goodluck.
     
    Last edited: Dec 20, 2018
    5argon likes this.
  8. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    Hi, there,

    It's shocking but there is undeniable truth in it. Unity doesn't make money on users making successful games. And I remember they are saying they don't want to compete with their customers(Asset developers in this case) when asked why they don't improve Unity Editor and relying on Asset developers to fix their problems. Well, of course, besides subscription, Asset developers are who brings money. I think it explains their mentality but I still have some faith that they want us to be successful in the long term.

    What should we do to make them to listen? Will they ever change? It feels like I'm the only one bitching and it makes me feel bad. There probably many before me who tried but they all gave up. Who knows. But I'll have to keep on pressing since I'm responsible for this project. (To be honest, I hoping that this project breaks peacefully so that I can go back to the drawing board and reevaluate)

    Going back to "Reloading Assemblies" fiasco, I understand about "Serializing" to save states but I still think it's doable without reloading assemblies each time. I think they took the easy route by reloading everything instead of figuring out the optimization. This would not be an issue for small projects and no one really cared. For large studios, they have the manpower to do it themselves but I'm stuck in between.

    This poses huge problems for unwarned future users like me and they should fix it before they are saying "Performance by Default"
    It's a shame.

    Cheers!
     
  9. castor76

    castor76

    Joined:
    Dec 5, 2011
    Posts:
    1,387
    Amen to everything you said. Sadly, I only use Unity because of the Asset Store. But a lot of the things that I buy in the asset store feels like they should be in the engine by default. Unity sometimes buys the assets and integrates into their engine, but sadly, a lot of them just went "away" and stopped developing after that. I spend almost $200 every month into Asset Store and that says something.
     
  10. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    Hi, guys,

    We all know "Performance by Default" is under a big campaign and I'm very excited. But there is one more thing which seems to be forgotten.

    How about "Performance by Default" for Editor?

    Unity Editor is really painful to use as a project gets larger. In my project, it takes about 9 seconds to start when clicked on "Play" on Empty scene with nothing in it. The profiling results show me it's trying to reload "Assemblies" and doing all kinds of thing that are not even on the scene.
    And it gets even worse when I load a simple scene and I'm really worried if I will be able to finish the project this way. Right now, it's "Pain in the a** by Default" (sorry about the inappropriate the word but I could not find a better alternative)


    UE in comparison, regardless of the project or scene size, the "Play" is instant. I know Unity does save states and it's necessary to serialize stuff. But UE does the same thing. Changes in "Play" mode are temporary and I don't see why Unity needs to take so much longer to start "Play"

    It's been like that for many years, perhaps from the beginning and I think it needs to be fixed now. I strongly feel that it's more important than the "Performance by Default" for the runtime, because, it's still far down the road before it matures and not everyone needs ECS.

    But working with Editor, everyone has to deal with it and everyone can benefit immediately without adopting anything.

    If it's not so easy to do something about it, at least tell us what's going on and how to avoid such a long start up.

    One thing I find is that there is an attribute, "InitializeOnLoad" causing the delay in "Play" Why?? I understand that it's is designed to call some initialization when an Assembly is compiled and loaded but why during "Play"? I think Unity shouldn't reload the assembly at "Play" at all so that it can't happen to begin with. It should reload only when the assembly is changed.

    One of the reasons I really like Unity is because of the faster Compilation time compared to UE. Thanks to C# but it loses all its advantages because of how slow the Editor is.

    Please, start the "Performance by Default for the Editor" campaign too.

    Thanks.
     
    Xblade-Imperium42 and Roni92pl like this.
  11. mgear

    mgear

    Joined:
    Aug 3, 2010
    Posts:
    5,118
    I think in the Megacity or other unite videos they mentioned how pressing Play would instantly start the game,
    and same for loading large scenes in editor (data is streamed in, so scene opens instantly, while things are still loading..)
    and other editor improvements has been mentioned (like multithreaded/background importing, faster/incremental compiler).

    so that sounds good!
     
  12. Grimreaper358

    Grimreaper358

    Joined:
    Apr 8, 2013
    Posts:
    466
    Editor performance has been discussed earlier this year. The main goal and what's been repeated was this.

    upload_2018-12-27_12-44-34.png
    Unity at GDC - Evolving Unity
     
    Peter77 likes this.
  13. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    500 ms integration time has created huge interests but Unity already decided to deprecate it, silently.

    https://forum.unity.com/threads/unity-incremental-c-compiler-deprecated.523993/page-10#post-4027198

    What a disappointment!!!

    It looks like we are going to have to continue to suffer for a while unless they look others way to minimize the pain.

    Right now, I'm not even asking 500ms iteration time.

    Currently, in my humble project, adding a "space" and compiling takes 30 seconds(I tried to create asmdef on all 3rd party assets and keep mime separate to a minimum, 200kb dll), click on "Play" on an EMPTY scene takes 9 seconds. I would be happy if I can keep it under by half of that.
     
  14. Grimreaper358

    Grimreaper358

    Joined:
    Apr 8, 2013
    Posts:
    466
    It's not really deprecated. The package manager version is but that's because they implemented it directly into the editor so there's no need for the package manager version.

    Link to post
    upload_2018-12-27_15-37-6.png
     
    Griz and Peter77 like this.
  15. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    You didn't read the whole forum thread. The compile time is no where close to 500ms. It's pretty much the same where it was. Try it yourself between 2018.2 and 2018.3

    Besides, this 500m stuff is about the attempt to reduce the compile time. I'm not even talking about that because, they dropped it.

    Instead, I'm talking about why it takes so long to just to click on "Play" to start.
     
  16. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    Is Unity back to work? I hope they are. It's been really silent since the 2018.3 release, as a matter of a fact since United LA, probably taking a long break after break. And in the meantime, I have to deal with the Editor getting slower and slower.

    It makes me keep banging my head on the wall, why does the Editor reload assemblies that are not being used? even on the Empty scene when I press "Play?
    Shouldn't the assembly be already loaded when compiled? And it should load only once until the next compile?

    Unreal Editor works similar to Unity, saving states and such, but their "Play" is instant no matter how big the project is.

    This severely hampers the development and I can't imagine how much more I have to waste my time throughout the project lifetime.

    In my humble opinion, Unity must fix "Play" before they do any other Editor's cosmetic changes. And I'll be really mad if they talk about "Performance by Default" before they do something about it first.

    This is really ridiculous and millions of users will have to suffer every day.
    There is no excuse for not fixing this and I'm getting really tired of waiting after clicking on "Play" and it makes my life miserable that I recommended using Unity fo the project.

    What do you say Unity?
     
  17. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
  18. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    Did you know that UE4 support Instant Play? Instant Play has been supported since UE3, probably even before that.

    But why can't Unity have Instant Play too? Please support the idea. It might be a simple change but it will make a huge difference for everyone. Even if it's not so simple, Unity should support Instant Play before they can talk about "Performance by Default"

    Here is the "Feedback" you can vote on.

    https://feedback.unity3d.com/suggestions/please-make-instant-play-mode

    Thanks.
     
  19. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    6,358
    :shrug:

    This is all to do with when the event to compile occurs. Unity just happens to use the Play option as that event.

    I've used both UE3 and UE4, and it compiles at different moments. And this usually has to do with the environment it's in (being C/C++ instead). I get just as bothered by its recompiling, it's just that it doesn't occur when you press play. Instead it's at completely different times, and takes super long as well.

    But I mean... who am I to really complain about it. It's compiling. It's gotta compile. Compiling takes time. Changing WHEN it compiles is really arbitrary and to individual preference. You prefer when UE does it, others may prefer when Unity does it. (there's actually a few things I like about it reloading everything on play, makes for fewer discrepencies when debugging)

    I would be less concerned about WHEN it compiles. And rather more concerned about how quickly it compiles.

    And honestly Unity is working on that. They're currently working on changes to the compiler and hopefully will have... oh I forget the name of it now... but like staged compiling where it doesn't always have to recompile the entire thing but only parts that change.

    ...

    Anyways, I have a MASSIVE project. Talking several gigs in size with multiple libraries and the sort. Sure I notice a delay when I press Play the first time, or after any change to the code. But honestly... the compiler isn't the part that takes the most time for me, but rather some of the other tools I have loaded up.

    And I'm on a 2nd generation i7.
     
  20. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    6,358
    It's just that in UE compilation/resetting doesn't occur when you hit Play. So it feels instantaneous to enter play mode.

    It's just that UE does it compilation and integrity checking at different times than Unity does. If you load it up you'll see the difference. Honestly I hate UE's, cause it will interrupt me in the middle of work.

    Personally when I press play a small delay doesn't bother me. I take the moment to pick up my controller and get into "play" position (i mean it's 5-10 seconds at most anyways). Where as with UE it'll be as I'm jumping around the project just working...
     
    Rotary-Heart and hippocoder like this.
  21. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,115
    Projects which are slow entering play mode can help mitigate this by using addressables, bundles etc or just stripping stuff from Resources folder. Things like that are prime culprits for slow play mode entry.

    There's work being done across the board already to address this and reloading assemblies is still the slowest part of compilation for my project as well.

    I have merged the related threads and duplicates you made, since those are the forum rules and I'm left with no choice. I too want faster editor playmode + "compilation", but we can't all cross post our way to victory.
     
  22. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    @lordofduct, Compile should be done only when you change your source code not every time you click on "Play" Unity let you choose when the compilation is done, manually, or automatically. And I'm not even talking about compilation time here and if you are referring to "500ms compilation", the attempt has been miserably failed and dropped.

    @hippocoder, I'm talking about the slow start on even an Empty scene. It takes 10 seconds to go into Play mode and profiling shows me it's trying to reload assemblies and initializing assemblies that are not even on the scene. Therefore, it has nothing to do with the resource or asset loading.

    If you click on "Play" 1000 times a day and have to wait more than 10 seconds each time, you will understand what kind of pain it's causing, especially when you know that it can be avoided.

    Unity workflow has many shortcoming and it's already frustrating, and for god's sake, I wish the "Play" an instant at least.
     
  23. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,115
    Yeah they're working on it. It's not ready yet :(

    It's the sort of change that takes a long time so your strategy should be built around fixing it. Did you measure where the time was spent?
     
    lordofduct likes this.
  24. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    6,358
    How do you know it can be avoided? Because UE doesn't have it? UE also has different requirements, it's a different environment, with different prereqs.

    It may not necessarily be a 'simple fix'.

    Ok, you wish it was instant.

    Wish away.

    We haven't denied you that wish.

    We all agree that there is a delay, we just don't really mind.

    And I only voiced that I find the UE workflow to be just as annoying, but in different places. Because that's the thing... this is a preference. You seem to be acting like we should all share your opinion. Sorry, we don't.

    But best of luck to you. Maybe other people will agree and will sign your petition.

    Though as hippocoder pointed out... they're already working on things to speed up the workflow. Unity already knows people want things improved in that regard. It's on their list. Soooo... what's the point of the petition then if all it's doing is telling them to do something they're already trying to work on.

    Because you think it's a "failure" so far (500ms compilation for example). So a feature that is "in progress" not being fully functional is a "failure"?
     
    MegamaDev and hippocoder like this.
  25. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
  26. daxiongmao

    daxiongmao

    Joined:
    Feb 2, 2016
    Posts:
    271
    Are you running it on pc but platform for iOS? Or similar.

    I notice my times when running in the editor everything takes longer when I am in iOS vs pc.
    My assumption is that the textures are in cached in formats for iOS and extra work is being done to them when playing so they can be rendered on dx. Possibly re-compressed to dxt. I haven't verified this but seems probable.

    It's not a huge difference but noticeable.

    May not be related since your seeing loading assemblies.
     
  27. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    @daxiongmao, I'm running it on PC only for now and it has nothing to do with graphics resources.

    @hippocoder, I really like to know if it's really in the work and how it is going? If they haven't told us, what's keeping it a secret?

    Thanks.
     
  28. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    6,358
    It's not a secret.

    They post blogs/articles/release notes/etc.

    They don't necessarily scream it from the hill-tops... but that's how companies are. You only scream the cool stuff, and only when it's ready. Less people get all butt-hurt that it's a "failure".
     
    hippocoder likes this.
  29. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    589
    I would like to see faster play times, if possible. It makes iteration much faster :))
     
    pvloon likes this.
  30. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    @hippocoder, I tried to search and when they announced that they will make "Play" faster. Only mentioned was "500ms" iteration time but it's has been dropped silently. Is this what you are referring to? What they were trying was to make the compile faster using incremental compiler but they utterly failed. Compile time didn't make much difference and it sometimes took longer. Besides, I don't think Unity tried to make any attempt to make "Play" instant. I hope I'm wrong. So how do you know? I'm really curious and it's really important for me that they are working on it.

    If they are silently working on it, I will be very surprised that they are working on it after all these years. Even if they are working on it, I wouldn't trust them that they will release it anytime soon unless the openly make an announcement on the roadmap. I think the instant "Play" is more important than Editor theme or any other editor related enhancement. It affects millions of users right now and it will be a huge win for everyone.

    I really want to hear from Unity what they have to say about this.
     
  31. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    6,358
    Good luck.

    I've wanted a response from them numerous times in the 9 years I've been using Unity.

    Never happened.

    And I doubt they ever will. They usually have PR and other public liaisons that control the flow of information. That's how large companies work. And as they get larger, the process gets even more bureaucratic.

    I see them pop their heads into the forums to offer assistance with documentation and support. But never explaining the practices of Unity behind the scenes. And I bet it's because for the same reasons when I've worked at various companies I was told, if not made to sign contracts, saying I wasn't allowed to discuss internal decision making with the public.

    That's just how companies operate. With good reason. There's a reason 'corporate espionage' exists... where competitors try to figure out the inner workings of a competitor so as to get an edge in the market.

    At best you'll get a vague response like "we're working on that" or "it takes time".

    ...

    On the upside you have someone on your side with joshcamas.
     
    Last edited: Jan 14, 2019
    Laicasaane and hippocoder like this.
  32. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,115
    Verbose answer for anyone really, not just you (for generally discussing this):

    As more of Unity's core components are DOTS-ified, this will make much more sense, even if you are not using ECS. The real solution is not to band aid constantly but do the job right, and this takes time.

    Until then you could share your bottlenecks in building and perhaps we can in the meantime lighten that load. In this case there is no black magic - Unity just has a huge task ahead of themselves.

    In my case I don't suffer much at all because I do not store much in scenes. So entering playmode is relatively OK with much of the world not streamed in. Each time you press play, unity builds a bunch of assets.

    If you are using addressables or asset bundles, that's a lot of work that you do not need to rebuild each time you press play.

    That's probably the biggest bottleneck. So that 9 seconds can probably turn into around 2 or so with your own efforts. If not then it points to a quite-heavy serialisation problem and architecture will help absorb that time until one day Unity can address it.

    Edit: merged the 2 basically identical threads which has caused a lot of redundant info posted twice, but there we go.

    Now armed with more information, I can see you are using a number of assets which are the root cause of all this lengthy entering playmode lark. You should take it up with them too, or invite them to enter this discussion so they can explain their choices.
     
  33. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,115
    Is this Gaia being the cause?
     
    dadude123 likes this.
  34. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    Gaia is one of the culprits and likewise several other common assets. They are reloaded and reinitialized at every click on "Play" even though nothing changed between the sessions.

    To clarify, I'm not using any assets bundles or resources. So it has nothing to do with the resource. The profiling result I showed uses just Empty Scene with nothing loaded, yet it takes close to 10 seconds.

    Sure I use many assets, around ~10(I can't say it's too much) Sure, 3rd party asset developer might be doing something wrong in their initialization routine.
    My original question was that why does the assembles be reloaded and reinitialized each time it goes into "play" mode?
    They only needs be reloaded and reinitialize when the assembly changes. To me it, it doesn't make sense at all.

    If Unity devs have designed the engine with the right mindset, it should never reloads and reinitializes anything unless Assemblies change. It will then prevents badly written 3rd party asset to take much start up time in the first place.

    Like I said before, in UE, Edit, and Play mode is basically the same mode with Tick frozen at 0 except particle, audio, rendering, therefore, going into "Play" can be instant and you can go in and out of Play mode as fast as you want.
    Of course, UE saves the state just like Unity between the sessions but it doesn't reload assemblies to each time. I never thought something so obvious as this can become a one of the biggest pain for me. There is more stuff but this overwhelms everything else I have to say.

    Oh, well...
    From my long experience with Unity, Unity will never do anything unless they publically announce with a timeline. The put minor stuff like "Dockable window", "Font Changes" into the roadmap and make a big deal out of it during keynotes. If a feature as important as this not on the roadmap, I know a fact that they are not going to do anything and that's why I asked you how you know if it's in the work.
     
  35. M_R

    M_R

    Joined:
    Apr 15, 2015
    Posts:
    415
    assemblies need to be reinitialized because any
    static
    field needs to be reset at game start (or at least between plays) or else the second time you enter playmode you do from a dirty state and you cannot test anything meaningfully.

    the alternative would be to ban all
    static
    fields, and this is unlikely as Unity uses static fields for their internals

    ps: in UE you don't have assemblies to reload, either c++ (that idk if it can be reloaded at all) or blueprints (that are their own language and runtime, optimized for UE, and don't have static variables) (*at least last time I checked)
     
  36. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    @M_R, if that's the main issue, the solution is simple. You can save the values, can't you?
     
  37. M_R

    M_R

    Joined:
    Apr 15, 2015
    Posts:
    415
    if you have your own runtime, yes (maybe). but mono/.net does not allow to "reset" the assembly (i.e. have static constructors run again) without unloading and reloading the entire app domain.
    also most values that need to be saved are not even serializable (e.g. events that you subscribe to)

    the only thing "lighter" than that would be having an editor AppDomain and a runtime AppDomain, and Loading/unloading only the runtime AD when entering/exiting play mode.
    but it will break the entire Unity ecosystem (editor code would not be able to communicate directly with runtime code). and that only if Unity actually supports AppDomains...
     
  38. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    I'm not a mono expert but the limitations seem arbitrary and there should be a way to take a snapshot of your game state and restore them back. It doesn't need really sophisticated serialization since it's doesn't need to save/load to files and support backward compatibilities. As crude as taking memory snapshot would be ok if it possible.

    I wonder how UE does it so well and it has been working since several decades ago.
     
  39. 5argon

    5argon

    Joined:
    Jun 10, 2013
    Posts:
    1,122
    In UE I am guessing, because you can compile each Blueprint (that is equivalent to GameObject in Unity). Imagine you can compile each GameObject separately and then they work together in kind of asmdef way. That would be the next level of isolation taken beyond programming to the game engine, and I can imagine it does not need to reload anything unrelated just by scanning what's available in the scene. While I appreciate the isolation ECS paradigm can provides, it is not as integrated to the engine but rather a pure programming concept. Currently making a new absolutely empty scene in my big game still takes 15 sec to enter the play mode consisting of nothing but cornflower blue bg, because it doesn't know there's nothing important in the scene but it look at the whole project still. The fact that new comers will not able to realize this until years later is also painful because you have to grow your project first.
     
  40. M_R

    M_R

    Joined:
    Apr 15, 2015
    Posts:
    415
    another issue is that Unity does provide startup attributes, like
    InitializeOnLoad
    ,
    RuntimeInitializeOnLoadMethod
    ,
    PostprocessScene
    , etc...
    that is forcing to scan all code for all methods with the attributes and execute those methods, each time you reload.

    a better approach would be to put those attributes at the assembly level (i.e.
    [assembly: RuntimeInitializeOnLoad(typeof(Foo))]
    ) so that it only need to scan the assemblies. or even keep a whitelist of assemblies that have initialization code and only scan through them.
    ...unfortunately, that would be a breaking change.

    @chrisk you could take a memory snapshot from a "level below the runtime" (like emulators providing save game) but it would be the entire managed memory allocated. that could easily be gigabytes. copying GB of memory to disk would be definitely slow.
     
  41. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    @M_R, sure, asset developers may use IntializeOnLoad wrong way, but you won't have that initialization problem if you don't reload the assemblies everytime you "Play" in the first place and Unity should've made it more foolproof.

    And why save to disk? Memories are cheap and I rather spend a few dollars if it has options to support in-memory copy.

    No matter how I think, Unity is architectured very badly and I don't see them fixing it anytime soon.
    I'm well into the project and I'm regretting so much why I decided to give Unity another chance.
     
  42. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    6,358
    Agreed, they should have made it more foolproof.

    But they didn't.

    And as a result, because of that baggage. It's not so simple to retroactively resolve the issue.

    So when you talk about how simple it should be... not necessarily. The product carries a lot of baggage with it. They can't go and break existing code to fix what you consider a simple fix.

    Adding more complexity. Fun. Handling for if the memory is available or not. Also not as straightforward since the memory we're referring to comes from mono and is not directly maintained by Unity (which gets into a huge years long argument about Xamarin licensing).

    This I completely agree with. Unity in the early years was designed to be novice friendly. And as a result they made tons of choices that bit them in the butt years later.

    Now they're trying to remedy this problem, but it's a slow process, because they need to balance moving forward and making a more professional product... while not breaking existing code. They have a large established user-base they can't just abandon.
     
  43. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    404
    Hi @chrisk,
    1) Are u using latest Unity 2018.3.1f1 at the time of writing? If not try to upgrade your project to that version. Backup your project before proceeding.
    2) Have you removed incremental compiler package? After I removing that package, I can enter play mode a lot faster.
    3) If 1-2 does not work, try to create a repo project with all the art assets removed and submit as bug report. A lot of bugs have been fixed after I submit the bug report.
     
    lordofduct likes this.
  44. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    @lordofduct, thanks for the sharing. If they can't fix it with old baggage, and they want to stay in business next 10 years, the only option I can see is to make the V2. The current Unity to me still feels like a beta(too clunky, riddled with bugs, unfinished features) and they have been like that past ~15 years. It has very gleam future since their mindset hasn't changed much.

    @optimzie, I have few asset dependencies that don't want me to be on the latest and shiniest. Many asset developers don't want to support beta and move quickly to the latest release. They also seem to be bitter, shooting their own foot working too diligently.

    A quick test showed me it's a bit faster but not a significant improvement like Unity claimed. Lesson learned: don't trust Unity as is and I'll never will. They will have to earn it the hard way now.
     
  45. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    404
    Btw have u tried Assembly Definition Files?
     
  46. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    Yes, but it just makes compilation faster, just a little bit.
     
  47. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    6,358
    Yes they should.

    That's what versions 2017 and 2018 have mostly been. Huge changes to the core product. Swinging direction. They've actually been slowly introducing code breaking changes over these versions.

    But all of that takes time.

    That's why hippocoder and I have been talking about Unity already working on lots of these things. They have been, and those changes are reflected in the last several versions of Unity.

    This is the flow of the Unity ecosystem.

    And sure, it can be slow and clunky. And it does feel like it's buggy and no where near as polished as Unreal.

    Here's the thing though... Unreal's engine first debuted in 1998, 7 years before Unity's initial release. The same year Unity was released in 2005 was when Unreal released that they were working on UE4.

    Unreal was also professional focused from day 1 (that engine cost a fortune back in the 90's). It wasn't until 2014 that UE opened up to indies (well technically UE3/UDK was released a few years prior, but was full of gimped features because it was trimmed down for indies/licensing reasons).

    Where as Unity only started focusing more professional around that same time.

    So yeah, UE feels way more polished. I totally agree. It has nearly a decade more dev time, as well as a much more higher tier client base for the entirity of its life. (there's a lot Epic could do with the several hundred thousand dollar licenses they sold back in the day... keep that in mind when comparing to how Unity was one of the early 'free to develop' engines... hence its novice/indie target experience)

    Unity wants to get there... that takes time. Completely pivoting the core focus of a company as large as Unity is not a simple task.

    If that timeline is too slow/indeterminate for you... well, there's always Unreal Engine 4.

    I ain't going to lie, we've considered jumping ship from Unity to UE4 ourselves. But we have such a well established code base at this time that finally allows us an efficient development cycle... leaving now would be a huge shot to the foot. (also UE4 doesn't lend to our visual style that well)

    Cause pivoting a company that's only 2 people in size is hard. I can sympathize with Unity having to do it on their scale. While also still having my list of gripes.
     
    Last edited: Jan 16, 2019
    5argon likes this.
  48. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    I've been in game development business since the mid-'90s and I watched every engine very closely ever since then. UE4 is pretty much a new engine written from scratch. UE4 started 10 years later than Unity but it's light years ahead of Unity already. Dealing with old baggage doesn't really justify the slack. I've helped EPIC to integrate DX10 renderer and released somewhat AA title in UE3 just before jumping to Unity. Why not use UE4? I love C#, and it's difficult to find good UE developers. I've been just watching Unity for about 10 years and last year's Unite Berlin got me excited and I decided to give another look.

    ECS is so awesome and it feels like the day when you have to create graphics packets manually for PS2 GPU. You have full control at the bare metal and it can get any lower than that.

    And the new network stack. I think the networking was the weakest link in Unity's subsystem and they seemed to determined to fix that. They promised to bring the best performant network stack last summer with full development transparency but where is it now? There is no update since the initial dump of last Fall. No roadmap, no nothing.

    After spending a few months, I realize the Unity Editor is basically hasn't improved at all past 10 years. Still buggy, very cumbersome to use, no plan to remove pain points other than few cosmetics makeovers. The new Prefab is basically very annoying, it has a fundamentally bad design. One thing I didn't know was that it gets slower and slower as your project size grows. It explains why there are so little AAA titles in Unity.

    I'll be so mad if they talk about "Performance by Default" again without addressing the laggy Editor. The user will have to opt-in ECS/Jobs system to take advantage but Instant "Play" can affect millions of users right now. I love C# because it allows faster iterations but the Editor loses all its advantages. And the question I have is that if there are no iteration advantages, why do I have to deal with the inferior old garbages.

    Anyway, I'm stuck for now and my rant will continue. I hope I'm not the only one.
    I bet there are many but they learned that it won't do any good and gave up trying to have Unity to listen.
    I'll keep ranting until I hear what Unity has to say.
     
    Last edited: Jan 16, 2019
  49. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    6,358
    UE4 did not start 10 years later than Unity. If it did, than it would have started in 2015... which it did NOT.

    UE4 started development in 2003, in 2005 Mark Rein revealed that it was in development since 2003 (citation). It was several more years that it was unveiled in 2012, fully released with a new licensing scheme in 2014, and finally get the modern licensing release in 2015. So yes, it was 10 years after based on when indies could get their hands on it with the modern licensing scheme.

    But it came with a decade+ of development time, along side 3 previous products that all grew/developed and researched as well. 15+ years of development history on their engine since UE1 is not a black box from development on UE4. The mere idea that it would be is bonkers.

    Compared to Unity released in 2005 from a company founded just the year prior. So released on only 1 year of development. UE4 released on 11 years of development and another 5 years of experience.

    Welp, I guess it doesn't justify it for you.

    Toot toot.

    Cool, sorry it didn't meet all your expectations. It ain't a perfect product.

    It hasn't improved at all in the past 10 years... yet you list ECS, a new feature in recent versions.

    I've been using Unity for the last 8+ years... I assure you, it has WAY IMPROVED. You think it's bad now... you should have seen it back then.

    As for the networking not having a roadmap... how about this article from just a few months ago?
    https://blogs.unity3d.com/2018/08/02/evolving-multiplayer-games-beyond-unet/

    Yep, a indie/novice targeted engine has pain points that lead to it not having many AAA titles.

    Rant away.

    But your rambling in so many odd directions, making feature requests for "instant play" when you seem to have issues with bugs, networking, etc etc.

    You just seem all over the place.

    So as long as you rant, don't be surprised if some of us are like "huh?"

    You demand for changes, changes are already being made, and you seem to just be upset that those changes aren't here yesterday. And insist that since Epic took care of this since the 90's (which you clearly have so much experience with)... why isn't Unity there yet?

    They're working on it. They're not Epic.

    Epic, a company currently valued at something like 15 billion. Unity... struggled to justify their 2.6 billion dollar self-valuation last year. It's sort of a non-starter to compare the resource availablity of the 2.

    And that's sort of my only argument here. Because don't get me wrong, Unity pisses me off a lot of the time. I've highlighted that multiple times so far.

    I just don't think it's fair to compare them to Epic/Unreal, a much older and more flush company.

    Especially when it could be argued the only reason we have things like UE4 available to indies like it is because of companies like Unity changing the market the way they did.

    ...

    But i guess if you got Epic to listen with your ranting (so I assume that name drop there was all about)... hey, who knows maybe it'll work with Unity.

    Personally though, it sounds like the developer equivalent of the lady who complains every time she goes out to eat in the hopes of a free dinner.

    But hey, to each their own. I usually just move tables at that point, and the forum equivalent... unfollow thread.
     
    Last edited: Jan 16, 2019
  50. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    393
    I have no intention to argue with you. Obviously you and I have very different backgrounds and have different views. I made it clear that I wanted to hear what Unity has to say. If they don't say, they don't say, but don't speak for them such as Wish Away, Rand Away, that's very rude!