In this specific case they are probably equivalent, because a1 is a field.
In general if a1 is a property you could not know how it's "backed" (where it saves the value).
If it saves its value on a field then accessing the property is nearly/as fast as caching its value. If it has to calculate its value every time/has to access a Dictionary/other complex object then it could be better to cache it.
In ASP.NET often a1 could be a Session[...]/ViewState[...] objects (they are like Dictionary in the end, so they work in a similar way speed-wise), so if you access it in a tight for or while cycle sometimes it could be better to "cache" its value.
In general this is premature optimization. You don't do it unless you need it.
To give some classic example:
public class MyClass {
// A field
public int Fast1;
// An automatic property backed by a field
public int Fast2 { get; set; }
// A property backed by a field
public int Fast3 {
get { return Fast1; }
}
// Each time you call this property, some calculation is done
public int LittleSlow1 {
get {
int j = 0;
for (int i = 0; i < 1000000; i++) {
if (i > j) {
i = j;
}
}
return j;
}
}
// This property is backed by a collection. There is a
// scan of the collection to retrieve the value.
public int LittleSlow2 {
get {
return ignoreme["LittleSlow1"];
}
}
public Dictionary<string, int> ignoreme = new Dictionary<string, int>();
}
One of the reasoning against properties is that they are nearly identical to fields in the way you use them like myprop = 5 or x = myprop + 1, but for that way they "hide" to the programmer the potential cost of using them, while when a programmer calls a method he knows that the method could be expensive.
c1in first snippet?