Unity editor performance, a slow decline

I recently updated some old work from 5.6 to 2019 with a pitstop in 2018.

There's slow but consistent slippage in terms of editor speed and responsiveness during common and frequent operations: playmode enter/pause, editor panel display, object selection updates, panel resizes, etc.

I wanted to just raise some awareness, if you use 5.6 then 2019, the responsiveness and general feel has a noticeable decline. I don't think this is any one thing, but instead just the slow accumulation of performance cost from additional features or logic.

I hope someone at UT keeps an eye on this stuff going forward.

 

Weird, for me it has always been the complete opposite. When upgrading the project to a newer version of Unity, entering play mode has always been sped up.

 

Well, as anyone would imagine, the speed at which any program operates is kinda bound to your hardware and surely enough Unity grew over the years and got more complex under the hood which can explain why the same hardware runs its previous versions faster.
What you could do instead is test how your project runs on the same hardware after compilation in different Unity versions to see if there is a speed difference in the operation of your end product with Unity version being a variable in the equation.
In the end that is the only thing that matters - how it runs on the customer device.

 

While that's definitely a high priority, I respectfully disagree that it's the only thing that matters. Editor performance can have quite an impact on developer productivity and comfort.

I agree that increasing hardware performance over time is a factor that should be considered, though it needs to be balanced with keeping our usable hardware usable, too, so I'm all for calling attention to it if and where it happens. (Hi Unity Hub, what are you doing with 198mb of my RAM?)

 

Good point, as I just experienced, this small program can even cause other problems, seemingly unrelated to its area of application.

As for the developer comfort - it's not what the user sees or even remotely cares about. Some things we have to endure and besides, as I already said, Unity being just a tool of choice here, it really grew, especially in recent years, so no wonder that the same hardware that ran version 5 fast is now slower with version 2019.
I'd argue that a good comfy chair has more impact on developer comfort and productivity, than milliseconds difference in editor UI speeds. Of course there is no need to go absurd here - a really laggy UI can drive anyone mad, but as far as I know that's not the case with Unity, at least, not yet. Most of my time in Unity I work on a decent workstation (i9 and so on), but sometimes, when on the move, I use an old 2013 HP notebook (still an i7 though) and I can't say that Unity lags on it even slightly.

 

I agree that our customers don't care. I'm talking about the impact it can have on the products we make, and customers definitely care about that.

It's pretty easy to make custom editors get really slow just by virtue of how the GUI API works. I'm not talking about milliseconds, and I'm not talking about slow hardware.

Yeah, Unity runs great on even my old workstation class hardware. This is all high-end stuff, though. Not everyone gets the luxury to work on this kind of gear. And even for those of us who do, lets not encourage more frequent upgrades where more efficient software could have had the same effect.

 

There are several growing threads in the 2019.3 beta forum about editor performance degradation, including some responses from UT staff. The 2019.2 - 2019.3 jump was when I really noticed it, especially now that the editor becomes unresponsive during both compilation and reserialization. It's added some definite friction to my epileptic attempts to trial and error a way into DOTS.

 

"Working great" is kind of relative.

As a software user, I tend to be extremely sensitive to application responsiveness - how fast keystrokes are rendered, how quickly commands are rendered, etc.

"Unity working great" is again, relative. Older versions of unity were faster and more responsive. It's not just entering playmode, the exit from playmode is also important - player pause transition from full screen - etc.

Another example, if I am moving through the hierarchy, there is a slight lag the first time I'm hitting an object before editor pops up while some objects get cached.



Some will handwave at this "we're talking milliseconds". The delay becomes more of a burden if you quickly click through multiple items sometimes, as the client lags. This is not a custom editor issue.

This is not a productivity issue, its an irritation/quality of life issue.

And yes, the editor has become slower over the last 5+ years.

 

My biggest problem with this statement is that there are third party assets that have the same functionality as Unity while simultaneously having better performance. Bakery, for example, is faster than the current lightmapper provided by Unity.

https://assetstore.unity.com/packages/tools/level-design/bakery-gpu-lightmapper-122218

 

I notice that one especially when you re-focus the Editor after making a code change. If you focus by selecting an item in the Hierarchy or Project tabs the item shows as selected immediately but the Inspector doesn't update until after the code is recompiled and reloaded, which can be many seconds on a large project.

It could be worth doing a GUI redraw before initiating the compile sequence. This is a case where the metrics would look worse (as it would add one frame's duration to the effective compile time) but for some workflows would be less distracting and potentially a bit faster.

 

Yeah, you really need to be very careful about metrics vs 'feel' for many of these issues.

As a game dev community we should understand the importance of fluid feeling feedback and responsiveness.

Also, a lot of the caching stuff is a mixed bag. Many editors and the like actually are very responsive after the data has been cached.

But like - take a good sized project, select an item in the folder and just hit the down arrow rapidly - you can see the delay as the inspectors load and your inputs being ignored. This is much slower than it was a few years ago.

The feeling of 'sluggishness' revolves largely around the inputs being dropped.

 

Damn was looking forward to 2019 and Rtx.

 

Once 2019.3 is officially released I fully intend to download and start playing around with the new features. Everything we've gained these last few years completely outweighs any performance losses that have come with them in my opinion.

 

Pretty much this. Plus I would mention the fact that they are actively working on improvements, refactoring, tweaking. It's not like it is dead in the water.

 

Like angrypenguin said, hardware performance needs to be taken into consideration too. Perhaps the Unity 5.x experience was just as bad with the average computer from that time.

I agree that it's a pain though when software is sluggish. Substance tools are like that since it's one big hotwired system - which has advantages though so you get the good with the bad. Perhaps Unity is doing something similar in specific areas.

At least they finally fixed the thing where you created an asset and then as you renamed it, half the name was teleported to the starting position as Unity refreshed the window. That used to get my hackles up, even when I knew it was coming.

 

That is a good example. Another good example is the Turbo Switch Pro asset:
https://assetstore.unity.com/packages/tools/utilities/turbo-switch-pro-60040

 

@zombiegorilla or @hippocoder - hey would you mind deleting this thread. I was just really grumpy when I posted this. After thinking it through - UT has really been doing a good job on editor performance.