For the QA personell checkin this, please read https://discussions.unity.com/t/715019
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
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.
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
18.3a11
18.3b3
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.
2018.3.0b2 - Editor Deep Profile #1
2018.3.0b2 - Editor Deep Profile #2
2018.3.0b2 - Editor Deep Profile #3
2018.3.0b2 - Player Profile
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?
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.
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.
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.
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.
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.
