When you change a Transform in any way, an internal notification message gets sent to components on the same GO and all its children. This could become expensive depending on the components reacting to it. For physics components, often they needed to perform a (relatively) costly update to ensure that physics was synchronised. This update happened synchronous to the Transform change as well. It also meant that if you modified a Transform in multiple steps like setting position, rotation or scale separately then it happens multiple times.
In 2017.2, due to internal requirements of the C# job system, this change notification was removed from the Transform system and replaced with an alternate method that used the C++ job system to retrieve a set of Transforms that have changed. This meant that component owners such as the 2D and 3D physics teams needed to deal with these consequences and make changes that ensured that legacy behaviour was maintained but also that the new behaviour could be used.
Now when a Transform changes, no components are updated because there isnât a notification from the Transform system at all! This means its faster but it also means that the associated components need to be synchronised to the Transform change(s) but it is deferred until required.
So when is it required? From the physics system POV, a SyncTransform is done prior to updating the simulation during fixed update or a manual physics simulation. This always happens. So, you can change hundreds of Transforms hundreds of times and no components get updated, so if this was a pattern in your project before, you get that back and only the Transforms that have changed get processed, just once, no matter how many times they were changed.
Now to ensure support for previous behviour we need to perform a SyncTransform prior to any physics query to ensure that the query is using the latest changes to physics. Whilst this guarantees previous behaviour, it has a small cost associated with performing it, even when no transforms have changed. This is the AutoSyncTransforms option in 2D and 3D physics. With this off, the only update is prior to the simulation being run but means physics wonât be in sync to any changes youâve made until the next update. You are free to manually SyncTransforms which is the call that is made when AutoSyncTransforms is on.
When we perform a SyncTransform, we do most of the work off the main-thread so in sum-total, the actual update should be faster as previously everything was on the main thread however, performing an AutoSyncTransform prior to any query is work we didnât do before. Even when no Transforms have changed, thereâs a slight cost which is a pain however the team dealing with Transform dispatch (as itâs known internally) are improving this.
Therefore, the best performance is when AutoSyncTransforms is off i.e. itâs only syncâd prior to updating the simulation. Only call SyncTransforms if absolutely essential and avoid calling it if not needed.
This is the solution we were forced to implement due to the Transform change notification being removed in the Transform system. I hope it provides some useful background on what changed.