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!
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
To follow up a little, the current reasoning is that the two are not comparable as the additional time reported now accounts for unreported time from before. So does it appear slower looking only at those numbers yes i agree it does but it doesnt tell the whole story that the additional time was just hidden before and you now see it.
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?
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?
I’m just the messenger here as i was not the original dev who looked into it someone on my team did so i’m working off information that was passed on. I will loop back around and validate with them that they did in fact do such testing and find out more about which profiler marker was added and try to determine why it was added.
2020 still would have the same marker though can’t promise 2020 to be more performant but it is something we are actively testing within the editor and trying to find places where it can be improved.
I do want to mention on thing as well us closing 1 bug about a regression that spans over 2 year of changes doesnt mean we won’t still actively work on the larger issue of Editor performance. Did the bug help bring attention to a possible performance issue that was slowly introduced over years? yes, but we also have places where these larger action items can be better tracked outside of the bug reporting system. The reason for “wont fix” also boils down to our resolution options. “By Design” sounds worse (IMHO), “Not reproducible” diminishes the fact that there is a genuine feeling of a issue, “Fixed” would just be blatantly wrong.
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.
Dont get me wrong it was just this particular case that the reason it was closed was that after 3 days of investigation it came down to the profile marker and we felt like we found the overall cause of the report. As i said we keep these larger issues at a more global level in different software as having 100+ bugs of “the editor feels slower” can cause some details to be lost so we combine them as needed elsewhere and close the bugs so other non global bugs dont get buried.
Editor performance I can tell you is something that is high on the priority list not just for my team but for Unity as a whole and we know there has been issues in the past where new features causes the editor to slow down all around even if you dont need that feature and we dont want that to continue as a trend.
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).
I dont know the exact count of windows that have been converted to UIElements but any that have possibly are better.
So i had the dev run the testing again without the profile marker and his comments were “I have removed the profile marker in the latest trunk and observed that the CPU time is around 80ms which is same as in 2017.4 version. With the profile marker turned on we get an additional 20-30ms CPU time” From what i can tell about this profiler marker is its at a higher level “UpdateScene” to be exact. This function is responsible for a lot of updates from updating the time, to ticking the player loop, to ticking input, ticking rendering calls and setting up the gfx device for the frame (this only names a few of the more majour ones it does a lot more as well). Now most of those inner functions already had profiler markers but previously there was a lot of time spent doing all the set up and initial calls that was not tracked so i believe this is where the 20-30ms we observed comes from.
In this case with the data in the bug about the profile number being higher it is the additional marker that accounts for the change thus that resolution. But as i’ve stated we have a larger task of editor performance that is constantly being worked on. Are we sitting back going “DOTS will fix things”? No not at all even in a DOTS world the editor will still be (from my knowledge) the interface between you the user and the engine no matter what the underlying runtime looks like. The Editor HAS to be performant there is a lot of us (and we are hiring more) that are not working with DOTS whose job it is to make sure the non DOTS runtime continues to provide what is needed.
I also get that there are a lot of people who feel the editor is slower which is why i’m willing to keep this discussion open. Can you narrow down the feeling to any particular event or action or workflow? What is it that you feel is slower? A response of “everything” really wont help us narrow down to a possible issue so any more specific details you can give would be appreciated.
