Feedback (Case 1206572) Editor UI performance regression

Editor UI performance has significantly worsen compared to earlier Unity versions.

Spoiler: Video

Spoiler: Profiler 2019.3.0f4

Spoiler: Profiler 2017.4.34f1

I didn't select one of the peaks, but a sample that seems to be an average, to make a fairer comparison.

[Edit]
As a bonus I've now also added a screenshot from 2020.1:

Spoiler: Profiler 2020.1.0a17

[/Edit]

Reproduce

1. Create new project in Unity 2019.3.0f4
2. Execute "Window > Layouts > Default"
3. Open Profiler Window
4. Change Profiler from Playmode to Editor and start recording
5. Constantly resize the Inspector panel
6. Stop Profiler
7. Repeat the test with Unity 2017.4.34f1
8. Compare the CPU timings in the project of both profiling sessions

Actual
UI performance is significantly slower in Unity 2019.3.0f4 than in 2017.4.34f1.

Expected
Faster or at least the same editor UI performance as earlier Unity releases.

Notes

1. Unity 4.x editor UI used to be faster than 2017 I believe, but I don't have a pro license where I could run the profiler in 4.x.
2. Please reproduce this issue on Unity 4.6 too.
3. Please use hardware similar to the PC I used to submit this bug-report with. You probably can't reproduce it on high-end machines.

PS: Please let us keep this thread professional and emotionless.

 

Thanks. Quick question if i may, does 2019 have different (perhaps more?) subwindows e.g. inspector, asset store, package manager open by default than 2017? That might explain some of the performance loss when resizing as presumably the whole editor ui has to redraw? I only have 2018 so can't easily answer this myself!

 

Nope, it's the same number of windows. Actually they're literally the same windows

 

I've updated the first post with a 2020.1 profiler screenshot. 2020.1 is faster than 2019.3, but still significantly slower than 2017.4, which is slower than 4.6

 

QA was able to reproduce the issue and it can be found in the public issue tracker now:
https://issuetracker.unity3d.com/is...dot-3-editor-ui-redraw-performance-regression

Would have been really interesting if you would've tested this against Unity 4.6 too.

Thank you QA!

 

Good job Peter. You're a one-man QA army

 

Hey, I just received an email from Unity:

This response makes no sense to me. The UI draws 2-3 times slower than in 2017 releases. Who knows how much slower compared to 4.6.

Why would you mark this issue as "Won't fix"? I mean it's not like you're trying to make Unity slow on purpose, that would be absurd!

 

That makes sense.

However, based on this, wouldn't it be possible to exclude the previously-unreported-time to make a proper apples-to-apples comparison and verify there is no regression?

 

Please don't make comments like this.

It makes devs less likely to address your feedback, and undermines the goal of the thread.

 

I disagree, and I disagree with your post, and I think your previous post also decreases the chances of getting a fix, since it ignores the original issue and evidence, but sure. I'm out of this thread.

 

So, if the issue is explained because older versions of unity did not include certain aspects of ui processing in the profiler, can we assume that the benchmark of 2020 still does? And therefore 2020 is more performant than 2019?

 

Hey Phil, thanks for your reply.

As an end-user, all I see is earlier Unity releases feel much more responsive. I want new Unity releases to feel responsive too.

Closing the bug-report creates the impression that you don't care. I actually don't think that people at Unity Technologies don't care, but it's what closing the bug-report signals to people outside the company.

The goal should be to fix these editor UI performance regressions and not to get lost in details whether it's because of this or that. Resizing the Inspector panel was a great way to easily show the performance difference of different Unity versions in a bug-report.

If 2019.3 is slower than earlier releases, then it's an issue. In this case the report should be kept open/active until the issue has been fixed, that is when 2019.3 is as fast as e.g. 2017.4 as mentioned in the report.

 

Is that currently still a lot of editor UI still not convert to UI Element yet that has much better performance?

 

I can't understand who in Unity seriously thought that "Editor is not slower than it was, profiler just got new markers" is a good explanation.

I watch Peter's threads closely and I got a strong feeling that Unity staff don't want to really investigate performance regressions at all and they just hope that DOTS (or something in future) will make it better.

I can confirm that 2019.3 Editor feels much more unresponsive and slower than previous versions, especially old 2017 and 5.X releases. It's not because there are new markers previously hidden. It's just absurd. Moreover, I can't tie that slowness to a new SRP and PacMan because editor performance lies in a different domain (And I hope it is).

 

Resizing docked editor windows, exactly what I used as "is slower" demonstration for this bug-report. It's even visible in the video that 2017.4 resizes more smoothly than 2019.3.

Please use hardware similar to my setup, you most likely can't reproduce it on high(er) end machines.

 

In our case the difference is staggering from 2018.3 to 2019.3. In editor we never dipped below 60 fps during play mode and after updating unity it goes down to even 30 fps (with spikes of 15 fps), making VR testing a headache. All accounted for with EditorLoop in the profiler. Amount of open editor windows has a negligible effect on this.

Note this is a play mode issue for us, and as such really concerning. It's not about the editor handling being sluggish (we have found it quite performant in fact), the game itself runs much slower.

 

Yes, I can extract some examples from the "everything is slower" statement.

Window resizing as it was mentioned above feels and also looks slower. Creating new assets sometimes can hang the editor for a few seconds, and overall it take more time that it was before. It's not tied to specific projects, I just create a new LWRP template for 2019.2.f17.

Also we can talk about enter play mode times, they increased to, but it's obviously happened because of the package manager and old mono reload-every-assembly behaviour.

My PC specs are not that bad: GTX 970, i5 4690K on 4 Ghz, 24GB of DDR3. I don't have an SSD, but that was never a problem when I started with Unity. It's not even a problem with Unreal.

 

Also I can confirm that somehow Linux Editor is much quicker and smoother (cold launch times and overall performance) than Windows. But it has more bugs so I can't be sure if it's ready for any real work.

I was testing on latest Manjaro with XFCE.

 

You guys ought to stop complaining because ... ECS!
Just kidding
I didn't believe the editor was sluggish, I thought that was me getting used to modeling in Medium so I installed 4.69, FRAPS and ... HOLLY F***AMOLI !

Empty scene

4.6.9 feels super smooth, resizing updates windows between 60 and 120fps

2019.3 feels painful, windows refresh at ..... 23fps !!!!!!!!!!!!!!!!!!!!!

That's nearly a 6x slowdown

Did you rewrite the editor in javascript? Because it sure feels like a web page now.
A regression like this ... I've never seen, even Maya with 30 years of bloat + autodesk.

My advise: Don't despair, some of the new stuff is awesome. Just invite Nicholas for an informal meeting, freely pour some alcohol so he gets chatty and infiltered and let him bust your balls. Or clone him.

EDIT: orbiting in the 3D view: 120fps on 2019, 240 fps on 4.6.9, on a 144hz monitor. 2x regression in performances in the 3D view.

 

Even though FRAPS is not recommended for that kind of measures (and Unity staff always says so) we can clearly see the difference between the two editors when it comes to a resizing and scene view.

 

Can this be used to track down specific performance regressions and accurately measure editor performance?
https://developer.nvidia.com/nsight-graphics
https://developer.nvidia.com/tools-overview

 

yep, this is an awesome tool and may help find out why the 3D view is 2X slower when the engine itself is much faster at pushing polygons.

I will bet all my pocket lint that it's the OnGUI autolayouting code that got the shaft.

@interpol_kun is right FRAPS ain't the right tool to perf something - in the absolute. Relative bench might be dependable because it does feel more than 2x slower refresh rate side by side.

To UT: the impact it has on us is worth considering: back in 4.6 I was addicted using the editor, now it is a chore, unpleasantly unresponsive. Reference to what was discovered in the 70s about perception (again, poke Nich's brain)

 

Not sure if this is the "right" thread but compared to the regular Editor windows (inspector, project, ...), the Shader Graph one feels like running at 5 FPS when dealing with animated materials.

One artist in our team still has a 4th gen i7 (or i5, not sure) and they can basically move the viewport around and wait for 1-2 seconds. Same with zooming in and out. Even my machine (threadripper 2950x) is having a hard time.

(Not sure if this is something related to general editor performance or just the ShaderGraph team. I can provide the link to the shader file if necessary / make a bug report with it included).

 

Just to chime in:

• 2019.0.3f starting play mode is painfully slow.
• Adding a new C# file to the project sometimes hangs the editor for at least 10 seconds
• Switching from VS to Unity after saving a file hangs the editor for at least 10 seconds
• Opening and closing lists of objects in hierarchy/project tab is visibly slower than in old Unity versions

 

I have tested the latest release candidate (2019.3.0f4) and the problem persists:


As you can see, editor loop takes half of the frame time. EditorLoop was almost unnoticeable before and now it takes a 3 ms chunk and a 5.5 ms chunk.

Edit: this is in a build in the same hardware:

Spoiler

 

Submitted as (Case 1210658) Performance problems with animated ShaderGraphs

 

Also submitted Case 1209047 for extremely unresponsive editor using a large Shader Graph. Filed 7 days ago, posted the case number in the Shader Graph forum, but still no one's looked into it yet.

If a Shader Graph editor window is open that contains a large graph, after pressing play in an empty scene, editor freezes for 20+ seconds while the Shader Graph window refreshes itself before going into play mode. Also about a 5-10 second freeze when changing Shader Graph property names. Can someone investigate this please?

 

Take your time to find and fix those issues, have a good luch. We can wait a reasonable amount of time, it's a lot better than being left unheard. We will be glad to hear more as you will dig it deeper.

 

Good luck! And thank you.

 

Sorry to clog this thread up with Shader Graph specific issues, but just wanted to let you know that my particular bug report was confirmed under a different entry in the issue tracker:

https://issuetracker.unity3d.com/issues/shader-graph-unresponsive-editor-when-using-large-graphs

Hopefully we can get updates about Shader Graph performance issues in the following thread, thanks:

https://forum.unity.com/threads/adding-removing-modifying-properties-is-very-very-slow.800139/

 

There is editor hang-up when you add and hang-up when you connect node. Please could you create SG like Blender Cycles.
In Blender, shader nodes viewport is fast and instant. It is disconnected from rendering viewport which is compiling and rendering.

 

Please let us know in what version the changes are expected to land, thanks

 

Great, thanks

 

@phil-Unity Any news on this item?

 

If it's really this... What a high level of incompetence!