Considering caching transform changes

The Transform component stores data only relative to its own parent. This means that accessing and modifying a Transform component's position, rotation, and/or scale properties could potentially result in a lot of unanticipated matrix multiplication calculations to generate the correct Transform representation for the object through its parent Transforms. The deeper the object is in the Hierarchy window, the more calculations are needed to determine the final result. 

However, this also means that using localPosition, localRotation, and localScale has a relatively trivial cost associated with it since these are the values stored directly in the given Transform component and they can be retrieved without any additional matrix multiplication. Therefore, these local property values should be used whenever possible.

Unfortunately, changing our mathematical calculations from world-space to local-space can over-complicate what were originally simple (and solved) problems, so making such changes risks breaking our implementation and introducing a lot of unexpected bugs. Sometimes, it's worth absorbing a minor performance hit to solve a complex 3D mathematical problem more easily.

Another problem with constantly changing a Transform component's properties is that it also sends internal notifications to components such as Collider, Rigidbody, Light, and Camera, which must also be processed since the physics and rendering systems both need to know the new value of Transform and update accordingly.

It is not uncommon, during a complex event chain, that we replace a Transform component's properties multiple times in the same frame (although this is probably a warning sign of over-engineered design). This would cause the internal messages to fire each and every time this happens, even if they occur during the same frame or even the same function call. Ergo, we should consider minimizing the number of times we modify Transform properties by caching them in a member variable and committing them only at the end of the frame, as follows:

private bool _positionChanged;
private Vector3 _newPosition;

public void SetPosition(Vector3 position) {
  _newPosition = position;
  _positionChanged = true;
}

void FixedUpdate() {
  if (_positionChanged) {
    transform.position = _newPosition;
    _positionChanged = false;
  }
}

This code will only commit changes to position in the next FixedUpdate() method.

Note that changing the Transform component in this manner does not result in strange-looking behavior or teleporting objects during gameplay. The whole purpose of those internal events is to make sure the physics and rendering systems are always synchronized with the current Transform state. Hence, Unity doesn't skip a beat and fires the internal events every time changes come through the Transform component, just to be sure nothing gets missed.