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

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.

 

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.

 

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.
P.S.S. Alternatively, we could just push for .Net CoreCLR and solve the root of all our performance problems.


EDIT:
Yeah, I'm just realizing this thread was about EDITOR performance optimizations...
Ugh.

 

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).

 

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.

 

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)

 

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

 

Please port Inspector window and all components to UIToolkit

 

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.

 

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.

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

 

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"

 

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.

 

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.

 

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.

 

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

 

Faster ASTC texture import time with more formats

 

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.

 

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

 

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.

Spoiler

"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.

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.

 

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.

 

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!

 

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.

 

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.

 

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

 

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.

 

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

 

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.

 

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 . 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.

 

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.

 

Multithreaded asset importing

It's honestly sad to have to wait hours for textures to import when switching to a new platform and seeing my 24 thread cpu being bored out of it's mind while unity uses a single thread to re-import the tens of thousands of textures one file at a time

 

I didn't know that PNG cannot be decoded on multiple cores. That's a bummer. Also shows that things are a lot more complicated that we'd like to think especially in a huge system like Unity.

 

Then the question becomes, which source texture formats import the fastest? PNG has the benefit that the source textures are rather small and thus your repository size isn't gigantic by default. However, if there are big import wins for using uncompressed TGA's as source textures rather than PNG's for example, then this could be worth a thought.

 

Flif seems pretty interesting, but its nowhere near popular status

https://flif.info/

Maybe in the future, at least its an open format.

 

Memory optimization, faster loading SRP projects, lesser size of the projects and lesser size of Unity.
I have situations when closing Unity (2020.1), application is hunged up



I hope 2020.2 will bring more performant editor when working in SRP.

 

Add checkbox "create new project without packages".
And when user import project from older version unity, ask user "Import without pacakegs" "Import and add packages".

When im not use any packages. And when Unity add packages, I then need to delete them manually.
But before that I have to wait 3 minutes for the project to open.

When I remove unnecessary packages, my project opens in a few seconds. Against 3 minutes with "default" packages.

For example im not use rider and vs code and visualstudio but unity add it to new projects.
Or im make empty 3d project and not need 2d.sprite and 2d.tilemap but unity add them.

 

P.S. The better way is show list of chekboxes were user can them self select witch packages it need for add to new project or for imported project

 

Oh, another thing. There's two tools made recently to help us figure out what's going on when things are taking up time:
- The editor iteration profiler
- The "hold on" box when Unity's frozen.

Those are great ideas, but have some problems:
The editor iteration profiler just doesn't work very well. That could be fixed, but:

The editor iteration tool is important enough that there needs to be some different priorities here!

The "hold on" box (made by @Aras' team) has this problem:


That's not very much information! I'd really like to get some way to tell exactly which assets Unity are touching when I alt+tab back from my editor. So while it's a step forwards to know that it's the AssetDatabase refreshing that's causing a bunch of waiting, I'd really like to know why the asset database needs to spend several seconds refreshing after compilation is done!

I also wonder about this one:


What is Application.Message, and why does it at times hang the editor for 5-10 seconds?

 

This is extremely important - happy to hear it's being worked on
Multithreaded image decoding is nice and all, but the wins from working on multiple files at once are going to easily exceed being able to import one file with many threads on modern cpus

 

How about ETA of on demand asset importing that u can just use editor right away without needing to wait all assets fully imported? I think this feature has been announced long time ago but seems like it's still not happening in 2020.2 yet.

 

Yup! Same Issue here , My Project Size is Around 37GB , and Reimport take Ages . Sometimes i just go to Bed. , Performance for import and reimport should to be Faster and like other mention importing 1 Part of the Project each time for Big Projects is Huge Problem.!

Multithreading is must.!

Thank you.

 

i heard about that too!. But i Didn't see it Yet, Sometimes importing 1 Stuff inside Project make you wait for ages and you can't keep working on it. , would like to hear about that!

 

i'm also so confused About that one , the Messages Almost make no sense. Sometimes i Dont Even know why the Reloading is happening.! Thanks for Mentioning That Important Points...!

 

Hi,

Does anyone know what may have changed from HDRP 7.5.x to HDRP 10.2, and i get exponentially lower performance ?

Before I was getting 15ms CPU and 3.8ms GPU and now 25ms CPU and 11.6ms GPU in the exact same project, same game window resolution, with zero changes. Just imported the same package in the two Unity versions (2019.4.15f1 with HDRP 7.4.3 and 2021.1.0a9 with HDRP 10.2) and started the same demo scene in the editor.

Seems every camera rendering in my scene takes up a lot more ms than in 7.5.x or 7.4.3, so they add up to something unsuable, while in 7.4.3 performance was great.

I did tests in HDRP 10.2.2 as well and performance seem to be same as bad and extremely slower than HDRP 7.4.3 or 7.5 in all my tests.

I post comparison photos for reference.

Note that this is the exact same project, without a single change in anything, besides the Unity and HDRP version. Also i made sure no background tasks were running in any of the tests.

EDIT:

I post also a photo of HDRP 8.3.1, for reference, is better than 10.2, but slower than 7.5