Property vs Field. Which is faster?

The problem is not that a property is slower than a field. A property is actually a method (or a pair of methods). What those methods do and how expensive they are depends entirely on that method.

It's usually just a waste of time to cache the Transform component manually as Unity already cache it internally. All other short-cut-properties do no longer exist (.renderer, .rigidbody, .collider, .light, ....)

You declared a so called "auto-property" which is the same as doing:

 private static GameManager m_instance;
 public static GameManager instance
 { 
     get { return m_instance;}
     private set { m_instance = value; }
 }

This property is just a wrapper for a field. However in theory a property could do anything within it's methods:

 public int MyProp
 {
     get
     {
         GameObject go = GameObject.CreatePrimitive(PrimitiveType.Cube);
         go.transform.position = Random.insideUnitSphere * 20;
         go.transform.rotation = Random.rotationUniform;
         return 42;
     }
     set
     {
         Camera.main.transform.rotation = Quaternion.Euler(0,value,0);
     }
 }

This property would create a new cube at a random position every time you read the property.

 void Update()
 {
     if (Input.GetKeyDown(KeyCode.Space))
     {
         int val = MyProp * 2;  // <<--- this line would create a new cube
         Debug.Log("Val is " + val); // <<-- this will always print "Val is 84"
     }
     MyProp = Time.time; // <<-- this will actually set the main camera rotation.
 }

Note that this is a perfect counter-example. Never do something like that. It was just an example to show that a property could perform any heavy task behind it's "variable-like" usage.

That's why a singleton is usually implemented like this:

 private static GameManager m_Instance = null;
 public static GameManager Instance
 {
     get
     {
         if (m_Instance == null)
         {
             m_Instance = FindObjectOfType<GameManager>();
             if (m_Instance == null)
                 throw new System.Exception("No GameManager found!");
             DontDestroyOnLoad(m_Instance);
         }
         return m_Instance;
     }
 }

This is a self-initializing singleton accessor. So the first time you "read" the property m_Instance might still be "null" so we use FineObjectOfType to find the instance in the scene and initialize the field. If there is no GameManager in the scene it will throw an exception.

If the GameManager was found the first time, any further access of that property will directly return the cached instance. It also takes care of marking the instance with DontDestroyOnLoad so it's persistant across scenes.

In general the overhead of a property getter is in most cases too small to even be measured. Also simple getters will most likely be inlined either by the compiler or by the jit compiler.