UGUI.Rendering.UpdateBatches Performance Regression

I didn't submit a bug-report for this issue yet, because this is most likely going to take me quite a while to create a simple reproduction case for it and I'm short on time. Therefore I'd like to know if Unity Technologies is aware of this issue, so I don't have to spend time on building a bug-report.

I see a performance regression in UGUI.Rendering.UpdateBatches in Unity 2017.2 beta, compared to Unity 2017.1.

UGUI.Rendering.UpdateBatches performs significantly slower in 2017.2 than in 2017.1 in my game. This is a performance degradation from 0.06 ms to 1 ms for me. 1 ms is a big deal if you have to target 90 or 60 fps.


Here are two profiler screenshots taken in a Windows Standalone 64bit build with Unity 2017.1 and 2017.2. See the highlighted/selected row.

Spoiler: Unity 2017.1.1p2 (performance ok)

Spoiler: Unity 2017.2.0f1 (performance issue)

Side note:
Notice that the whole game is also about 2 ms slower in 2017.2.0f1 by average, see "CPU". This even uses the new Physics optimizations (autoSyncTransforms=false in 2017.2). 2 ms is almost 20% of a frame if you target 90fps/VR, or 10% if you target 60fps, it's a huge deal.

 

Kickin' goals @Peter77

 

Give the man 2 t shirts, he needs them because he keeps bursting out the first with bug reports.

 

Two steps forward, five back at times it feels like. Thanks for finding and reporting these issues @Peter77

 

His entire family must be wearing beta tshirts by now

 

Thought we would try out 2017.2, hoping we wouldn't run into these issues. (Too much to ask? ) Aaaaand we are experiencing the same issues... 2017.2f2. Really needs to be looked at before release.

We see PostLateUpdate.PlayerUpdateCanvases taking much longer.

2017.1p3 we see it takes 0.29ms with 0kb GC Alloc, in 2017.2f1 we see it takes 5.85ms with 26.7kb GC Alloc

This is in the menu of our game where it is 'UI heavy'. But no issues in 2017.1p3!

The GC spikes resulting from all that allocation are causing lots of stuttering too.

@patrickf, yes, we have 8 Layout Groups (a mix of Horizontal/Vertical/Grid layout groups) that have ContentSizeFitters on them.

 

It's actually the whole street that wears them!

Every Friday night, the so called "Unity bugs festival" is being held here (for residents only, but I'm in the organizing committee, I could try to pull some strings for you). It's the attendees duty to wear that Unity t-shirt during the time, so I'm looking forward to everything UT can send to my direction.

We even have Unity logo cubes stuffed with candy, where kids can smash the hell out of them. It's such a lovely time

 

XD

 

I believe we're seeing a very similar issue, though I'm not 100% if it's the exact same issue or not which is why I'm posting... We're very antsy to jump onto 2017.2, and it'll probably be the last upgrade we do (we've a shipping production game) for a while after having kept up with all major & minor releases since ~5.3 and not had any major issues.

In 2017.2 however, many of our UIs have slowed very substantially -- some of them can take the game from 60-100FPS down to <30FPS.

The offending UIs, and indeed many of the UIs in our game, make use of some combination of: ContentSizeFitter + GridLayoutGroup + ScrollView

Occasionally we'll use a different LayoutGroup variant, but generally speaking the vast majority are a combo of at least two of the above three, or all 3. We're seeing some of these UIs, especially those with a number of children elements, have had their times jump by orders of magnitude.

I don't want to switch over to 2017.2 this moment to get the exact profiler trace (else I end up having to rm -rf /PROJDIR/Library when switching back to 2017.1, else the editor crashes immediately upon entering Play mode; reproduces every time) but from my notes we were seeing the offending times be in OnRectTransformDimensionsChange I believe -- it looked like it was basically 'looping', as if each component was setting a size and shipping a "DimensionsChanged" event, then... recursion, perhaps.

FWIW, after debugging it a bit I was able to gain some positive ground on the issue via adding a secondary Canvas and setting PixelPerfect=false, but really the major gains came from disabling the LayoutGroup or removing/disabling child transforms until there were just a few (ie <5 -- and we aren't pushing limits here, normally maybe 50 or so on the higher ends). I was also able to make some headway via removing the ContentSizeFitter and using custom code to set heights/widths appropriately; that's a tough one for us to make scale right now, though, given that we have an untold number of UIs that would need manually adjusted & code written for. If no other option, that's what we'll do, but we're going to try to avoid it for usre.

Note that I haven't tried RC2 yet, though just skimmed the notes and didn't see any indication of a fix here & based on the above post, am guessing that it didn't get into RC2 -- I'm at least hopeful that the issue we're seeing is the same as the OP's, and that you guys have a beat on it, but if you guys @UT think it may not be then let me know and I'll get some project files put together.

Am really hoping it's fixed by release, would be a bummer to have to wait to move over because of a UI render issue of all things -- but that's how gamedev goes sometimes, it seems! =D

Thanks in advance for any insight or guidance, much appreciate all that you guys do!

 

Thanks for the quick response! Good deal, glad it's at least on the radar & going to be fixed, was starting to consider just shipping our builds to our experimental branches with slow-as-molasses UIs! ;-)

Fingers crossed it maybe lands with f3, but either way will keep an eye out! Thank you, really appreciate it!!

 

I have not tested it yet, but f3 is released and the change log diff since f2 does not contain this fix...