(Case 1081996) UI Performance Regression

The UI of the provided test project runs about 1.5ms slower in 2018.3 than in 2017.4. Profiled a Windows Standalone 64bit Player.

Spoiler: 2017.4

Spoiler: 2018.3

Reproduce

• Extract project_2017_4.zip which contains the test project
• Open project with Unity 2017.4.0f10
• Build a Windows Standaline 64bit Player
• Run Player, choose "Medium" Quality and tick Window option
• Open Profiler in Unity editor and connect to Player
• Write down "Time ms" of "PlayerUpdateCanvases"
• Repeat the above steps with Unity 2018.3 beta

Actual
Observe 2018.3 runs slower than 2017.4.

Expected
2018.3 does not run slower than previous Unity versions.

 

Thank you for reporting.

For the QA personell checkin this, please read
https://forum.unity.com/threads/massive-performance-hit-due-to-ui.556402/
The project featured in that post was sent to QA due to prefab issue.
So if you need extra samples contact person dealing with
Case 1080570

 

My pleasure, Leonhard.

 

So at least for your issue (only 1081996) it appears as if its "by design". Let me explain why i've come to that conclusion.

So with 17.4 i was seeing that SyncTransformChanges was talking 0.19ms and 18.3 was taking 26.11ms (this is debug so more then a little skewed do to extra asserts). I found the single function call that's internals had changed between the two (transform.GetLocalToWorldMatrix(); for reference) and added more profiler markers around just that call. I'm now see SyncTransform being 0.88ms (self) on 17.4 and 1.32ms (self) on 18.3 and the additional check for GetLocalToWorldMatrix reporting 22.54ms on 17.4 and 22.59ms on 18.3.

The fact that the 22.54ms on 17.4 wasn't present until the additional profiler marker tells me there was a bug in the profiler in 17.4 that didnt report the extra time taken by the GetLocalToWorldMatrix function call.

I have reached out to the team that deals with the profiler to see if they fixed something related to that recently but thats the best conclusion i have as now the numbers for 17.4 and 18.3 line up and are similar enough as expected (accounting for some margin of difference between runs.

 

Just want to know that there is also a slight slow down that is caused by us internally turning on a Sync in the transform hierarchy that wasn't present in 17.4 this might also be part of it on occasion.

 

I used other tools to measure performance of the provided test project built with 2017.4 and 2018.3, to by-pass the Unity profiler. Just to make sure it's not an issue with the Unity profiler, which might display incorrect results as I understand your post.

The results are pretty much the same for me. Overall, the provided test scene runs about 1.5ms slower on average in 2018.3.0b1 on my computer. If this performance drop isn't related to UI, then something else in Unity seems to run slower in this test scene.

Here are the results measured with a tool called FPS Monitor.

Spoiler: 2017.4.0f10

Spoiler: 2018.3.0b1

 

So its interesting not sure exactly what happened but the performance team member informed me that the profiler shouldn't be a issue and upon a full rebuild things were back to "normal" and all the times lined up.

After that i kept digging to see if something stood out and have been unable to find anything as drastic as your example. There is a bunch of fluctuations for me between 0.95 and 1.10 but that happened on all 3 versions that i was testing 17.4 (public), 18.3a11 (public), and 18.3b3 (local build).
17.4

Spoiler

18.3a11

Spoiler

18.3b3

Spoiler

Could you maybe do a deep profile and see which function is causing the excessive time?

 

Sure. I was able to do a deep-profile in the editor only. If you know how I can deep-profile a player, please let me know and I will add the result here as well.

I have just updated to Unity 2018.3.0b2, you can find the results below.

Spoiler: 2018.3.0b2 - Editor Deep Profile #1

Spoiler: 2018.3.0b2 - Editor Deep Profile #2

Spoiler: 2018.3.0b2 - Editor Deep Profile #3

Spoiler: 2018.3.0b2 - Player Profile

Spoiler: 2018.3.0b2 - Player FPS Monitor

Perhaps you're unable to reproduce the issue, because your computer is too fast? Do you have access to an older one where you can test? Or alternatively, perhaps try to reproduce on a not-so-good tablet?

 

So yes i deep profiler in the editor, i was getting similar numbers so i think in Editor would have the same results. Could you possibly do a 17.4 deep profile as well similar to the #1 you posted above so i have a comparative mark?

I can try a older machine.

 

You can deep profile a player by building a regular development build + "auto attach profiler" options as normal and then invoking it with the -deepprofiling command line argument.

 

Spoiler: 2017.4.10f1 - Deep Profile Editor #1

Spoiler: 2017.4.10f1 - Deep Profile Editor #2

Spoiler: 2017.4.10f1 - Deep Profile Player #1

Spoiler: 2017.4.10f1 - Deep Profile Player #2

The 2017.4 player deep profile session was spitting out a lot of errors regarding profiler begin/end same mismatches, so not sure how useful the player profile results are.

 

@JJJohan Thank you for the info!

Here is a deep profiler of an 2018 player as well. I notice the 2018 runtime spikes a lot more than 2017, see the #2 screenshot for the spike.

Spoiler: 2018.3.0b2 - Deep Profile Player #1

Spoiler: 2018.3.0b2 - Deep Profile Player #2

 

Thanks.

So i'm at a utter and complete loss on this one. I've run it on my laptop, and my 6 year old laptop and still dont get any notable difference between 17.4 and 18.3. Sure there are ups and downs but those are on both versions and on average it seems to be very similar. The highest usage on 18.3 isn't any higher then the highest on 17.4 (they are withing 0.02ms usually).

I've tried both the project you gave us, and the modified project QA gave me which just had (according to them) 5x the number of object. No difference was detected.

I've even gone as far as adding more native profiler markers and the numbers line up.

The only thing i can think of that i know changed is the fact the Transform SyncFence was switched on. If for some reason you are hitting that where i am not i could see it causing a delay for you though not sure how you could "fix" it. I'll keep digging but its not looking promising.

 

I can offer to run custom editor builds, if you want to create those.

I've worked with some of your colleagues in the past on issues they weren't able to reproduce and they provided custom editor/player builds with additional Log's/Assert's for example, that I could run here and then send back the results.

Do you believe that would help?

 

Pm'd you

 

Any news on this one?
We experienced that the LayoutGroups are way more time consuming on 2018.3.0b9
For example we have a HorizontalLayoutGroup with Flexible empty GameObjects left and right and in the middle a massive scroll container with lots of GameObjects in it. And when we deacitvate the LayoutGroup after initial layouting the time is reduced by 3ms. If we activate/deactive the LayoutGroup on 2017.3.1p3 it made no difference at all!

We investigated this and came to this conclusion after seeing massive performance issues especially on older (android) mobile devices.

 

No news from my side.

Could you please submit a bug-report, as described in this document:
https://unity3d.com/unity/beta/guide-to-beta-testing#tab-3

If UT has that issue in their bug database, they have to look at the issue eventually. After you submitted the bug-report, you receive a confirmation email with a bug report case number. Please post the case number here for Unity staff to pick up.

 

Bug reported: (Case 1100091)