During 2017.2 beta, we found a performance regression in UGUI.Rendering.UpdateBatches:
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.
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.
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 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
