UGUI.Rendering.UpdateBatches Performance Regression (continuation)

During 2017.2 beta, we found a performance regression in UGUI.Rendering.UpdateBatches:
https://forum.unity.com/threads/ugui-rendering-updatebatches-performance-regression.496849/

I checked this 2017.3.0b6 today. Performance did improve in this area again, awesome! Unfortunately, according to my tests, it continues to be slower than 2017.1.1p2.

Code (CSharp):

1. UGUI.Rendering.UpdateBatches
2. 2017.1.1p2 = 0.06ms
3. 2017.3.0b6 = 0.15ms

Spoiler: Unity 2017.1.1p2

Spoiler: Unity 2017.3.0b6

The "TransformCangedDispatch" entry in the Profiler has been introduced during 2017.2, perhaps related to the performance regression?

Can we expect further fixes or improvements in this area, so that UGUI.Rendering.UpdateBatches is on-par with 2017.1 again?

 

We have not left 2017.1 yet due to these performance regressions. We tried 2017.3 briefly the other day but the performance was unacceptable. Most of our frame time was taken up by an "unaccounted" or "unknown" entry, which we hadn't seen before in Unity.

We have a deadline today, and we will be exhibiting at PAX Australian the rest of this week so I can't take the time out to try anything at the moment, but next week I can try again and report my findings too.

 

Hey so unfortunately no UpdateBatches will never get back to the same speed, but let me explain why.

Before (2017.1 and before) Transform changes would happen instantly and the CanvasRenderer would update any needed values. I.e. if you changed a position the changed element (and all of its children) would get a OnTransformChanged message which would updated any internal data structures right away doing its matrix recalculations along with other things. Same was true for parent changes.

In 2017.2 with the introduction of the TransformChangeDispatch all changes are held to a single point in time and then all processed together. For the UI UpdateBatches was picked as the logical last point to update before we did all of our processing. This means that UpdateBatches is essentially doing the work of all the OnTransformChange calls from before. If we never called the TransformChangeDispatch to update the dirty Transforms we'd end up in a very bad state.

The good news is, before OnTransformChange (for the UI system) was taking more overall time then what the new system is showing as the difference in UpdateBatches.

 

Thanks for the explanation, Phil!

 

The bad news is, before Unity 2017.2 contentSize fitter worked well

Spoiler: 2017.1

Spoiler: 2017.2

before Unity 2017.2 RectMask2d with subcanvas worked well

Spoiler: 2017.1

Spoiler: 2017.2

 

But this isn't really it right? When @phil-Unity said it'll never be as fast as it used to be, I figured he meant that when this bug is fixed, it'll still be a fraction of a ms slower than it used to be. (Not 15-20ms slower)

 

I still don't quite get this. How could the old version take more time, but the new one, that takes less time, perform slower?

 

I guess, the best thing you can do is to submit a bug-report and provide Unity Technologies with a project which they can use to reproduce the issue and test their fix against.

I believe he was referring to the 0.x ms difference. I hardly believe UT thinks 20ms isn't a big deal, that would be absurd.

However, I think it's important to send them a project to reproduce the issue. Hardly have I seen things getting fixed without actively being after it

 

Already done, and they advise to update to unity 2017.3 beta... Maybe they need to do real stable build before pushing users to a beta version.

And my bug was duplicates
https://issuetracker.unity3d.com/is...d-image-components-inside-the-rectmask2d-area
https://issuetracker.unity3d.com/issues/content-size-fitter-causes-large-performace-slowdown

with nice fixed version
Fixed in 2018.1.0a1, 2017.3.0b5

2018.1a1....