(Case 940893) Physics.SyncTransforms() performance issue

The Profiler in Unity 2017.2.0b6 shows that manually syncing transforms, once per update, is slower than the Physics system performance in earlier Unity builds, such as 2017.1.1p1.

According to the Physics.autoSyncTransforms information I could find, one reason to introduce this new API in 2017.2 is to provide a way to help to improve performance.

However, my tests show that physics performance is worse in both cases, with autoSyncTransforms enabled and disabled, compared to Unity 2017.1.1p1.

Manually syncing transforms (using Physics.autoSyncTransforms=false and Physics.SyncTransforms()) is about 1ms slower than the physics system in 2017.1.1p1 in my tests.
2017.2.0b6 - CPU time between 2.6ms - 5.0ms by average
2017.1.1p1 - CPU time between 2.3ms - 4.3ms by average

Please see the video attached to the bug-report.

Spoiler: Video

Reproduce

• Open user attached project
• Open Assets/Scene.unity
• Open Window/Profiler
• Press Play
• Write down CPU time.

Repeat these steps with Unity 2017.1 and observe 2017.2.0b6 is slower.


Expected
Physics should not be slower than in a previous version.

 

Excellent bug report and find Peter good work...

 

From what I understand, even with the autoSync off, SyncTransforms() is called before the physics simulation step. So if you're calling SyncTransform manually once, it's actually being called twice.
There are other things that would cause the update as you can see here.
And maybe have a dirty bit, making the test more difficult but not less important.

 

I think you're right. I wasn't aware it still syncs transforms even after telling the system to not do that. I've to check whether performance is OK if I remove that SyncTransforms() call.

Thanks for the info, very helpful!

 

Excellent find. Have you tested performances in builds (not in-editor), just in case?

I know sometimes certain features generate debug information in-editor and are therefore much slower. For instance, GetComponent() can generate GC allocs in-editor if the component was not found, because it creates a new warning message string.

But I'm not sure if a development build would have the same problem.... maybe the only real way to "profile" it would be to make a very physics-heavy scene and then compare framerates?

 

Yes, the numbers I posted are from a Windows Standalone build. But I'm not sure if that's really an issue, I need to re-test without calling SyncTransforms().

 

I profiled this case too now, where I do not call SyncTransforms(). CPU time did improve, but it's still about 0.5ms slower than 2017.1.1p1. Will update the bug-report now, to let QA know about the recent findings.

 

Unity just exposed physics sync in the API. Since access to the API can only be done in the main thread I wonder if this is why those old physics bits now show up in the profiler, where previously, they were done invisibly in a separate thread.

 

It does, thanks for the explanation!

It's a difference of 50ms according to my tests.
2017.1 requires about 4ms to complete one frame, 2017.2 requires 54ms. According to several other tests I did, it seems every project runs slower in 2017.2 and it seemed to me, according to the Unity project, that the cause are the physics system related changes.

I can't afford a 10x performance degradation in my project, which is the case if I just open it in 2017.2.
However, if it's as easy as turning off autoSyncTransforms to restore the performance of 2017.1 or make it even run faster, perhaps that should be the default setting then?

 

Really appreciate the wealth and depth of information.

 

I do wonder if there would be any performance benefit to allowing a mode where you can make particular rigidbodies never update from a transform automatically before simulation, for projects where the developer can guarantee that this will not happen.

 

Just dropping in to confirm that even with autoSync off and doing absolutely no manual Syncs, the FixedUpdate.ScriptRunBehaviourFixedUpdate entry in the profiler is about 2x slower than in 2017.1 for a script that does a bunch of Raycasts, CapsuleCasts and Rigidbody.MovePosition/Rotation

(for 3D physics, in 2017.2b8)

 

I'll admit that I tested this with a pretty huge character controller script that does a whole bunch of stuff. I'll make a better test later today and upload it here

 

Okay, my bad. I was wrong

The test I've made shows no performance difference at all. It includes:

• raycasts
• capsuleCasts
• OverlapSpheres
• computePenetrations
• direct rigidbody moves
• interpolated kinematic rigidbody moves (MovePosition, MoveRotation).

Actually 2017.2 even seems to perform slightly better for the PhysicsFixedUpdate task.

However, I still see a performance difference for my character controller script. I'll have to keep searching for the culprit. With all those physics queries I just cleared of suspicion, it may not be physics-related at all

I've attached the test project anyway for those who might be interested. Just open the testScene, press play, and look at the profiler.

PS: This is to be expected, but the performance difference in 2017.2 between having AutoSync on/off is absolutely immense. 11ms versus 650ms per FixedUpdate in my case. People will really have to be well educated on this feature, otherwise they may start wondering why their 60fps game suddenly runs at 1fps. At this point, I'm wondering if activating AutoSync should be an option at all... maybe just forcing people to understand syncing and having it constantly off would be a better option? I understand that the notion of rigidbody syncing might not be understood by a large part of the community, but the performance cost is just waaaaay too huge for this to be a viable thing to do

 

I dont understand why there is such a big performance regression since the engine has always been running in 'AutoSync on' mode?

 

I'm very excited about the performance gain of this new system with auto sync off and that part really sounds great!

I am concerned however that the has been no response to the claims of the _huge_ performance regressions in autoSync=on legacy mode. I will run some tests myself too to check but if the numbers are like what's mentioned here, it could be a huge deal. A performance regression of 60x like in PhilSA's case just isn't actually backwards compatible - perf behaviour is part of expected behaviour too.

 

If I read between lines from MelvMay's reply, it seems this issue is kind of bouncing between teams. The Physics team says it's faster (in the Physics system) and the bottle-neck is now in the Transform system.

I wonder if someone actually feels responsible to simply fix that it does not run slower in total, no matter what sub-system is causes it now.

I've attached my test project to this post too. It's the project I've attached to Case 940805.

Spoiler: Profiler 2017.1

Spoiler: Profiler 2017.2

I think from a customer point of view, it doesn't really matter what sub-system is slower. All I see is that it's 10x slower in total, which is actually a "breaking problem" I'd say.

 

I've tested Peter77's project with autosync off, and it really seems to me like the performances are identical. Sometimes you see some disparity but that may just be because you've accidentally landed on two profiler samples that are off the average due to some error margin. Actually I'm starting to think this may be the case with the difference I'm seeing for my characterController script. With the test I made yesterday and this one, I think it's safe to say that there are no problems with AutoSync off. The only real problem is AutoSync on.

There is no doubt in my mind that the changes made to physics were a great thing. The C# jobs system looks phenomenal and it's absolutely worth making this small sacrifice for it. Actually it's not even really a sacrifice, because the performances are actually a tiny bit better now with autosync off. (Please please please do not let this AutoSync issue slow down the integration of the jobs system! )

I honestly think the best way out of this is to not give any AutoSync option at all. The cost is just too high, people won't understand why their game runs so slow, and the work required/potential pitfalls of having it turned off are really not that serious. Unless I'm mistaken, the absolute worst case scenario is if someone tries to move a rigidbody with transform.position and then tries to raycast it at its updated position in the same frame. I really don't think this sort of thing will happen often; or at least not for the beginner users for whom the autosync option was made. In that situation, I think people generally would have the reflex to debug transform/rigidbody positions and notice that the rigidbody is only updated at the next frame. I'm sure we can afford this, from a user-experience/accessibility point of view

Besides, if there's only one way of doing things, I think it'll be much easier to educate people about it

 

That sounds like music to my ears. If you end up deciding that you should use that opportunity to fix most/all problems in Unity that are simply due to wanting to keep backwards compatibility, I'd definitely have a list of things that have to go away!

For instance....

• all the .materials, .vertices, .etc.... that return copies of arrays
• all the .transform, .rigidbody that do a secret GetComponent
• Camera.main that does a secret Find()
• all the RaycastAll, SphereCastAll, OverlapSphere that do GC allocs
• ...and especially this atrocity, since we have no alternative https://blogs.unity3d.com/2014/05/16/custom-operator-should-we-keep-it/

Most of the things I mentioned may seem like it's no big deal since we're not forced to use them, but when working in teams with less experienced programmers, it would make all the difference in the world if all of those bad things were just not available at all

 

Nah, it's always best to provide info. The community and developers can simply correct it. If there is not too much info, then there is even more guesswork, I know this from moderating this place over the years