Optimization is fun, but not easy... Not a single concept is always true. Combine this with multi-threading (think about the SMP machines and the newer hyperthreading processors) and optimization is almost a try and guess game, although some basic techniques do help a bit. MtnBiknGuy wrote: I would think #2 is preferrable, but I see that most C# examples use the style of #1. In fact, I often see the following in C# examples: #2 does one inutile assignment, #1 don't. But to solve this doubt, remove the "= null" (BTW, this isn't a good practice, as it defeats some useful compiler warnings) and just look and the generated code with ILDASM. I bet they generate exactly the same IL, as the maximum stack space is allocated on the method's entry. MtnBiknGuy wrote: Finally, I'm curious if there are any performance differences between the following two loops. If the JIT is as good as MS sells it, #1 could even be slightly faster than #2. MS says JIT does common subexpression elimination and code motion of loop invariants, which is exactly what you did, but sometimes the JIT could even do it without the need for another local variable (imagine that you have several loops). Notice that the JIT sometimes will do a better job than you. If T.x is a virtual property, and not a field, you can't safely do what you showed (T.x could have a side effect, e.g. incrementing a counter to keep usage count). Although sometimes the JIT hasn't all the info or time it needs to make all the possible optimizations, it has all the info it needs to always act safely. On a side note, you should make all of your timings on Release builds, because the optimizer is disabled on the Debug builds. Kant wrote: Actually she replied back to me "You shouldn't fix the bug. You should kill it"
