Search Unity

  1. Click here to receive a gift with your purchase of Unity Pro or Unity Enterprise.
    Dismiss Notice
  2. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

Feedback Editor Performance Optimizations - Which Improvements Would You Like to See?

Discussion in 'Editor & General Support' started by LeonhardP, Nov 9, 2020.

  1. LeonhardP

    LeonhardP

    Unity Technologies

    Joined:
    Jul 4, 2016
    Posts:
    2,290
    Hi everybody,

    In today's blog post, we're introducing the Performance Optimization team to you and highlight some of their recent accomplishments.

    As we're dedicated to focus on performance & iteration speed on the road ahead, we would like to hear from you which performance improvements you would like to see in the Editor to make your quality of life better.

    The thread will remain open for your comments until the end of November. Independently of this thread, you can also share your performance related feedback with us in the forum by creating new 2020-11-09_14-32-51.png threads and tagging them with 2020-11-09_14-32-12.png .
     
  2. mahdi_jeddi

    mahdi_jeddi

    Joined:
    Jul 18, 2016
    Posts:
    104
    I think there should still be more room for optimizing texture imports. 2020.2 made our import times more than 2x faster, I would love to see it become faster by utilizing more cores. The other big pain point for us is compiling the texture atlases, currently it looks to be completely or mostly single threaded even though these kinds of processes are multi-threaded by nature.

    One fix to these issues would be to let the system process multiple assets at the same time to utilize more cores, but I guess that has its own complications.
     
    GliderGuy and LeonhardP like this.
  3. oxysofts

    oxysofts

    Joined:
    Dec 17, 2015
    Posts:
    99
    Thanks for making this thread! What matters most to me is FAST iteration, it helps me keep the rhythm. In general, anything to speed up domain reload, recompilation and playmode entering/exiting.

    Recently I have been debugging our slow domain reloads (15-20s) and in each instance, the culprit appeared to be a scalability issue. Not all were Unity's fault, we do use some plugins, but I have found that Cinemachine would take roughly 350ms and ProBuilder a similar amount, up to 500ms on a bad day. (both filed and reported already) Both had to do with gizmos, as they seem to be traversing all the assemblies and types loaded in memory. Any code that traverse a large amount of ever-growing items (such as assets) should be thoroughly investigated for performance concerns and scalability problems, and if possible look for alternatives or ways to cache.

    In general with a fresh new project, Unity is a great and light feeling editor, but performance quickly degrades as the project grows and plugins are imported. For the future, I would highly suggest that the performance team concentrate their efforts on scalability, and it would help if they can get their hands on some large projects, 10-15+ GB assets and heavy on code e.g. 1500+ classes.
     
    Last edited: Nov 9, 2020
  4. GliderGuy

    GliderGuy

    Joined:
    Dec 14, 2018
    Posts:
    146
    Yay for performance!

    One thing I'm not sure has been given much love is AddComponent and Destroy(Component).
    GetComponent has likely already been super-polished by the performance team, but has AddComponent and Destroy(Component)?

    Not all games can completely avoid the use of AddComponent. And while I make it a priority to never use it — because the performance hit is impressive — there are cases where I feel it would be advised to use AddComponent, rather than trying to work around it.

    Take power-ups for instance — wouldn't it be nice and easy to just add a new "PowerUp" component to the GameObject that touched the power-up, and the component would just perform the power-up's effect on that GameObject? And what if that power-up was less of a power-up, and more of a unique attack or action?

    That sounds like an ideal and simple way to solve what would have been a potentially complicated problem!

    What if you had a large multiplayer survival game where "upgrading" yourself, specifically your abilities, was a key part to surviving? Shouldn't it be viable to use AddComponent for these in-game upgrades?
    Then... what if you had procedurally generated, AI-controlled enemies, too?
    And what if everybody started out as a simple, procedurally generated player, to further lean on the mechanic?

    All I'm saying is; it would be nice if AddComponent (and to a slightly lesser extent Destroy(Component)) would be viable solutions to these sorts of problems without you having to worry that it could come back and bite you down the road!
    Right now, it feels like they aren't viable solutions — simply because the performance hit is so large and they really don't scale well for games that decide to go down that path.

    I would love if AddComponent and Destroy(Component) were looked at!


    P.S. Nobody go touting about ECS. I am aware of its existence, but I still feel like this should be addressed. :cool:
    P.S.S. Alternatively, we could just push for .Net CoreCLR and solve the root of all our performance problems. :rolleyes:


    EDIT:
    Yeah, I'm just realizing this thread was about EDITOR performance optimizations...
    Ugh.
     
    Last edited: Nov 19, 2020 at 6:26 PM
    LeonhardP likes this.
  5. Kolyasisan

    Kolyasisan

    Joined:
    Feb 2, 2015
    Posts:
    325
    CoreCLR implementation and moving rendering operations of current frame to the next frame as in the player (in editor all rendering operations must be completed until a new frame can start executing, which drastically reduces performance).
     
  6. oxysofts

    oxysofts

    Joined:
    Dec 17, 2015
    Posts:
    99
    Another thing which is not properly supported in editor but works in built player is asynchronous scene loading. Scenes are a good way to modularize a set of features or a part of the map that can be loaded dynamically. Currently in editor, scene loading always results in a fake lag spike which does not exist in final builds.
     
  7. mgear

    mgear

    Joined:
    Aug 3, 2010
    Posts:
    6,298
    current wish list:
    - fbx import and re-import times (super slow on big CAD models, and you cannot do anything else while waiting)
    - fbx animation clips editing (literally have to edit meta files to create/modify clips, the inspector is too slow)
    - selected mesh previews (unity almost dies if you select multiple huge models *havent tested recently)
    - package manager (too slow fetching results)
    - animation window (almost hangs with complex animations from 3ds max, with hundreds or more of key frames)
    - unity startup time (i guess its getting slower with every new release, which is kind of understandable with all the new features.. but still would be nice to have fast startup times and perhaps lazy load things in the background if possible)
    - large texture imports (was already mentioned in this thread)
     
  8. MdoobM

    MdoobM

    Joined:
    Jan 4, 2018
    Posts:
    2
    When there are multiple display, there will be problems with clicking and touching。On multiple display, there will be many problems both in runtime and in the editor
     
    LeonhardP likes this.
  9. Onigiri

    Onigiri

    Joined:
    Aug 10, 2014
    Posts:
    152
    Please port Inspector window and all components to UIToolkit
     
    Jes28, LeonhardP and Ghat-Smith like this.
  10. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    7,810
    I would like to see and experience more love to assembly definitions.
    They suppose to help organise and speed up compilation time, a bit like dlls.
    But having too many of them, start clogging and slowing down compilation and entering into play mode.

    To me seems relatively straight forward solution.
    If asmdef and its dependencies and related inner files are not modified, don't ask compiler to recompile them, if at least once that has been done already. This data should be keept in the memory/temp for next play mode entries.

    Then compiler should only check for affected/changed asmdefs and files, which are not in any assemblies. And fetch stored precompiled asmdefs.
     
  11. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    5,162
    AssetDatabase V2 was supposed to enable working without needing to import all the assets first - with assets importing in the background and only blocking when they were needed. That's probably the most important thing to land, since it will make a lot of the times the editor is "slow" not matter, since it will be slow in the background.

    --------------

    This would help tremendously, as currently large amounts of data trashes the imgui-based editor. Both the default inspector and inspectors for built-in elements should be ported asap.

    --------------

    Static batching is still broken for multi-scene editing when playing in the editor. Here's a 1.5 years old writeup of what's happening:

    In Mesmer, having static batching enabled adds 1 minute to the amount of time that it takes to enter play mode. This bug will be present in every project that enters play mode with several scenes loaded, and has static batching turned on.

    ---------------

    When working with imported 3D animations in .fbx or .blend files, updating a single value casues the entire file to be reimported from scratch. If you have a bunch of animations in a single file, this means that it takes 30-60 seconds to eg. move an animation event or set a single animation to loop.

    The importer really needs to do incremental updates of the file to be useable.

    --------------
     
    JoNax97, mahdi_jeddi, Jes28 and 4 others like this.
  12. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    2,815
    This is also my number one issue that I like to see fixed
    "working without needing to import all the assets first - with assets importing in the background"
     
    Last edited: Nov 10, 2020
  13. Clavus

    Clavus

    Joined:
    Jun 6, 2014
    Posts:
    43
    Scene loading within the editor play mode is noticeably slower compared to builds (and in some cases many times slower), usually adding hiccups (which is terrible when testing in VR). It'd be great if you could take a look at that.
     
    LeonhardP likes this.
  14. OmegaNemesis28

    OmegaNemesis28

    Joined:
    Dec 1, 2012
    Posts:
    103
    Please, please, please, please

    Incremental compiling of build scripts.

    I cannot understate how important this feature is. I'm shocked this doesn't exist yet up until 2021 reportedly. It's a huge productivity killer in large projects, ie something AAA. Builds should not take upwards of 5-10 minutes to compile a single script change into a standalone executable on a modern workstation with a 12 core Haswell Xeon from 2014.

    I also really need to see ECS performance improvements, but I don't think that applies to this team/thread.
     
  15. benmultiplayerguys

    benmultiplayerguys

    Joined:
    Oct 3, 2018
    Posts:
    8
    Often it takes almost a minute to open Unity with my project, and it can take several minutes if I switch git branch and then return to Unity. It's just super-slow to respond to changes on disk. I started following this thread - https://blogs.unity3d.com/2020/10/06/tips-for-working-more-effectively-with-the-asset-database/ - but it was no help.

    Also:
    Very true. I've seen that, past a certain point, Unity starts to be slower than traditional C++ builds, simply because the traditional C++ toolchain isn't reimporting and rebuilding everything. Obviously most of the time I can test changes in the editor - but I work on multiplayer games where I need to produce builds so that I can run multiple clients at the same time.
     
  16. OmegaNemesis28

    OmegaNemesis28

    Joined:
    Dec 1, 2012
    Posts:
    103
    Yep exactly. And currently, Unity's recommendation for this is to run the server and client, or multiple clients, in the same executable or in editor and that just simply is not possible with all the other performance issues they have going on (especially in ECS) unless you strip the game waaaaay down to bare minimum. Which, with multiplayer games, results in unreliable test cases since performance and gameplay go hand in hand. I guess it's good for testing 1-5 FPS players? xD
     
  17. Jes28

    Jes28

    Joined:
    Sep 3, 2012
    Posts:
    635
    Faster ASTC texture import time with more formats
     
    LeonhardP and Lars-Steenhoff like this.
  18. MechaWolf99

    MechaWolf99

    Joined:
    Aug 22, 2017
    Posts:
    67
    Asset importing, updating and applying changes to already imported assets are probably the biggest thing for me. At least having them happen in a different thread would be nice.

    Besides compile times for script changes, and entering play mode of course, but I know you all are already well aware of those things. Haha.
     
  19. Alvarden

    Alvarden

    Joined:
    Feb 22, 2019
    Posts:
    24
    Terrain optimizations. That is something a lot of developers has been asking and despite the changes over the last years, there hasn't been any major improvement when it comes to performance, which makes it unsuitable for open world games, and much less for mobile games, which forces them to model their own terrains as meshes and/or depend on other assets that do the job.

    Better Scene Loading. The hiccups and lagging that happens during loading (specifically async loading) can be very distracting, especially in VR.

    Better Asset importing, as others in this forum have mentioned.

    UI: Either improve the standard one with the optimizations that TextMeshPro has, or replace it and use TextMeshPro as the standard one, giving the options for those who use the standard to migrate it to TextMeshPro seamlessly.

    Incremental Builds: this is something that is essential for large projects, and a lot of people ask.

    Multiplayer: i still don't know why Unity is still using the old UNet for multiplayer, and making us wait for DOTS that long. If DOTS won't be available for a while, at least improve the current Multiplayer solutions using the optimizations and practices of Assets like Mirror or Photon, which not only are more up-to-date, they also add more features that are more suitable for larger scale multiplayer games.

    Stability for assets, such as Addressables.

    Lastly, i'd like to see a Native solution for the movement stutter. I'll leave the article that goes in depth in that topic for reference (while the solution in the article is great, the only catch is that you have to use a custom Physics system, which is why i'm saying 'Native', that this solution could be implemented inside Unity, so that we can use the default Physics System. Not sure if it's possible or not, i'll leave it to you):
    https://www.kinematicsoup.com/news/2016/8/9/rrypp5tkubynjwxhxjzd42s3o034o8
     
    LeonhardP and Lars-Steenhoff like this.
  20. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    5,298
    For me, who works as a programmer, it's
    ReloadAssemblies
    . Every time I change a script, Unity freezes for a few seconds. Seeing it 8 hours each day is quite annoying.

    "Fun" fact: a while ago I reported that newer Unity versions are significantly slower when it comes to "compiling" or more precisely "ReloadAssemblies". On my computer at that time it was for an empty project:
    • Unity 4.6 = 2s
    • Unity 2020.2 = 6s
    I bought a new PC in the meantime (Ryzen 3900X) and Unity 2020.2 now takes 2s for ReloadAssemblies in an empty project.

    The editor performance worsened so much over time, that even new hardware isn't able to outperform Unity 4.6 on a PC from 2008. I was very disappointed when I saw that.

    upload_2020-11-15_8-34-18.png

    So I applaud you for introducing the Performance Optimization and Quality of Life teams and hope you're able to make the editor an enjoyable piece of software again.
     
    Last edited: Nov 15, 2020
  21. Wilska

    Wilska

    Joined:
    Nov 2, 2019
    Posts:
    5
    I would like to see some options like:
    Settings to define when script compilation happens:
    - manual (provide a button on the interface, maybe on the bottom right)
    - timed (check every x.x seconds)
    - on focus event (actual for VS code users)

    I feel the manual is the most important, everytime i edit a script (and save it) and go back to editor to check something i've to go through a compilation unnecessarily.

    I also feel the shader editor would benefit from the same options, the less unnecessarily compilations, the better for the user.
     
  22. villeHelin

    villeHelin

    Joined:
    Mar 27, 2013
    Posts:
    29
    What I'd love to see optimized are:

    1. GameObject null/non-null checking (this seems to be really slow)
    2. GetComponent<>()
    3. Raycasts

    These I use quite a lot in my games...

    Also this: static and dynamic batching. With these on I still got 400-600 draw calls in my horror game and the reason to many of the draw calls was: a) different light source is affecting this object b) multiple lights are affecting this object ... and I have just one light in my scene. Thus I wrote my own version of dynamic/static batching in C# and got the draw calls down to 100-180... Costs more CPU, but on on mobile I usually have much more CPU than GPU available...

    PS. I think MatrixMult4x4 or something like that was slow and even allocated memory!
     
    Last edited: Nov 16, 2020
  23. banan1234

    banan1234

    Joined:
    Mar 31, 2018
    Posts:
    111
    Something I haven't seens o far. During the early prototype phase, we made a simple, 30 mb scene to playtest our game, performance, etc. I have noticed one significant performance issue while trying to revert changes by pressing ctrl + z. The editor always freezes for a few seconds.

    It got several times better in 2020.1 compared to 2019.3, but the freeze still exists on a relatively small, 30 mb scene.
     
  24. Yozaro

    Yozaro

    Joined:
    Jun 28, 2015
    Posts:
    71
    These came to mind:
    1. More APIs that do not create new arrays on each call, but would instead let us give an existing array/list as a parameter.
    2. uGUI is rather slow, even when we follow all the best practices shown in Unity's blogs and YouTube videos. Any improvements here are welcome.
    3. This is more of a UX problem: I'm not using auto-refresh, but moving a script file still triggers compilation. The workaround now is to not use Unity's project view.
     
  25. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,620
    @mahdi_jeddi Hm, curious. I don't recall some specific 2020.2 improvement that would have made texture importing be 2x faster! Anything specific about your texture types/formats/settings? :)

    @Jes28 what do you mean by "more formats"?

    @mgear Yes.

    So, wrt all of these above - we've been spending some time on optimizing texture importing. Some bits have landed to 2021.1 alpha builds already, some more coming in alphas soon. I'll make a separate forum thread and maybe a blog post once 2021.1 alpha 7 is out. TL;DR so far:
    - General small speedups on all texture imports (~1.3x speedup), more speedups for some types e.g. panorama cubemap/skybox images (2021.1a2)
    - ETC format compression 2.7x speedup (2021.1a4, 1.4x speedup part backported back to 2019LTS)
    - ASTC format compression 2.5x speedup (2021.1a6)
    - PVRTC format compression 1.1x speedup (2021.1a8)
    - BC7 & BC6H compression minor (couple percent) speedup (2021.1a2)

    Also experimenting with having some options similar to "compress assets on import" editor preference being off, imagine like ability to globally set max texture import size. Many roles during a production don't really care about having 100% best possible texture quality, hypothetically if you could say "all textures, max size 512 pixels" locally without having to change import settings of everything that might be useful. This one is very WIP and needs a lot of UX and workflow thinking, but that's something we're playing around with. Hypothetical UI:
    Screen Shot 2020-11-19 at 1.04.18 PM.png Screen Shot 2020-11-19 at 1.04.35 PM.png Screen Shot 2020-11-19 at 1.04.42 PM.png
     
  26. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    5,298
    I would appreciate if you could create a separate forum thread, because I can think of a few questions I would like to ask, but at the same time don't want to hijack this thread :)
     
    GliderGuy and Aras like this.
  27. soleron

    soleron

    Joined:
    Apr 21, 2013
    Posts:
    221
    Not sure about these "accomplishments" mentioned in the original post.

    All I see is the last two generations of Unity becoming slower and slower.
    2019.x especially the LTS editor is visibly slower than 2018 LTS. And that on a much faster machine.

    2020.2 as I tested the latest version is almost as slow as Unreal engine, without providing the same quality visuals OR having the same amount of editor panels open. 2020.1 is also slower than the previous version.

    What I want to see, or rather, to stop seeing, is shaders compiling like they do for Unreal engine. Instead of picking up Unreal's strong points you have started piling up on negative points that they themselves are trying to get rid of.

    This was NOT there in version 2018 and previous and Unity was super-fast, regardless of your machine. (Unless of course you were using junk...) This is not the case anymore, and there is nothing anyone can say to convince me otherwise.

    The same scenes that used to load very fast in Unity 2018.x, almost bring my machine to a halt using the latest versions, despite having double the RAM and VRAM and on average about 30% higher performance compared with my previous machine. So there must be something the... "Optimization" team is doing wrong.

    My current machine: Windows 10 Pro - i7 - 32GB RAM - 512GB NVMe M.2 SSD with plenty of space, RTX 2070.
    My previous machine: Windows 10 Pro - i7 - 16GB RAM - 256GB SSD with little free space, GTX 860M.
     
    Last edited: Nov 20, 2020 at 6:08 PM
    tavovallejo, Alvarden and mgear like this.
  28. Jes28

    Jes28

    Joined:
    Sep 3, 2012
    Posts:
    635
    Unity provide us with some compression ratios of ASTC: 8bpp, 5.12bpp, 3.56bpp, 2bpp, 1.28bpp, 0.89bpp.
    Somewhat default one for textures is 3.56bpp (6x6), most useful for UI is 8bpp (4x4) but.

    For UI there no need for 8bpp but 5.12 is too low (it is almost 2 times difference :( ). ASTC has exact average between them 6.4bpp but Unity dont allow to use it.

    For textures often 3.56(6x6) is too much but 2.00(8x8) is too low (it is almost 2 times difference too :( ) ASTC has 4 formats in between but Unity dont allow to use any of it.
    At least average 2.67 (8x6) will be dream come true. Most of the times I want to set compression for regular texture into something average between 6x6 and 8x8.

    Summary: Please add at least ASTC 6.40(5x4) and 2.67(8x6) formats to texture compression dropdown.
    Smaller textures will increase performance of game :) So it is somewhat performance related :)
     
    Aras, GliderGuy and Lars-Steenhoff like this.
  29. soleron

    soleron

    Joined:
    Apr 21, 2013
    Posts:
    221
    And to point out what I mean, this is just the nice but simplistic HDRP sample scene.

    I got a scene with several highly detailed city blocks, a traffic simulation and hundreds of assets, including characters, using dozens of different PBR materials and high-resolution textures, loading faster than this in 2019.

    Lightning fast on 2018.x 1/3 of the time.

    upload_2020-11-20_22-21-2.png
     
  30. mahdi_jeddi

    mahdi_jeddi

    Joined:
    Jul 18, 2016
    Posts:
    104
    I saw visible improvements in import and sprite atlas compilation speeds. We have thousands of sprite atlases which use BC7 compression and crunched (automatic high quality, usually 8K textures, the sprites themselves are also huge and are imported as DTX5, automatic normal quality).

    I really thought that this is because of the thing you tweeted a while ago :p. Maybe it was some other optimization in asset pipeline that caused the improvements. I would still love to see how much the optimization you mentioned would improve things for us.
     
    Last edited: Nov 21, 2020 at 12:18 PM
  31. CortiWins

    CortiWins

    Joined:
    Sep 24, 2018
    Posts:
    65
    I'm doing this as a hobby with very small projects until now and i can already feel it. Must be hard having that all day. So yeah, i second that.
     
unityunity