If something.awesome is a field it is likely to be access each time round the loop as something in the body of the loop may update it. If the body of the loop is simple enough and does not call any methods (apart from methods the compiler inlines), then the compiler may be able to proved that it is safe to put the value of something.awesome in a register. Compiler writers used to go to a lot of afford to do this short of thing.
However these days it takes a very long time to access a value from main memory, but once the value has been read for the first time, it is coached by the CPU. Reading the value for a 2nd time from the CPU cache is a lot closer in speed to reading it from a register then reading it from main memory. It is not uncommon for a CPU cache to be hundreds of times faster than main memory.
Now if something.awesome is a property, then it is in effect a method call. The compiler will call the method each time round the loop. However if the property/method is only a few lines of code it may be inline by the compiler. Inlineing is when the compiler puts in a copy of the method code directly rather than calling the method, so a property that just return the value of a field will behave the same as the field example above.
Evan when the property is not inlined, it will be in the CPU cache after it has been called the first time. So ales it is very complex or the loop goes round a lot of times it take a lot longer to call the first time round the loop, maybe by more than a factor of 10.
In the old days, it used to be easy because all memory access and cpu actions took about the same time. These days the processor cache can easily change the timing for some memory accesses and method calls by over a factor of 100. Profilers tend to still assume that all memory access take the same time! So if you profile you will be told to make changes that may not have any effect in the real world.
Changing the code to:
int limit = something.awesome;
for(int i = 0; i < limit; i++)
{
// Do cool stuff
}
Will in some cases spread it up, but also makes it more complex. However
int limit = myArray.length;
for(int i = 0; i < limit; i++)
{
myArray[i[ = xyn;
}
is slower then
for(int i = 0; i < myArray.length; i++)
{
myArray[i[ = xyn;
}
as .net check the bound of arrays each time they are accessed and have logic to remove the check when the loop is simple enough.
So it is best to keep the code simple and clear until you can prove there is a problem. You make a lot better gain by spending your time improving the overall design of a system, this is easy to do if the code you start with is simple.