Chances are that if you are habitually applying C-style Micro-Optimization tricks when coding C#, like moving variable declarations out of loops, you are probably:
- Prematurely optimizing
- Doing it completely wrong
To demonstrate the point lets start by ignoring that there is a perfectly good Array.Reverse function in the framework and write our own:
static void Reverse1<T>(T[] xs)
{
for (int i = 0; i < xs.Length / 2; i++)
{
T x = xs[i];
xs[i] = xs[xs.Length - 1 - i];
xs[xs.Length - 1 - i] = x;
}
}
Now micro-optimize by taking the temp declaration out of the loop:
static void Reverse2<T>(T[] xs)
{
T x;
for (int i = 0; i < xs.Length / 2; i++)
{
x = xs[i];
xs[i] = xs[xs.Length - 1 - i];
xs[xs.Length - 1 - i] = x;
}
}
The IL (byte code) generated for both implementations is identical in both release and debug builds. If you don’t believe me then check it for yourself by using the ildasm tool.
Another micro-optimization would be to store a copy of the array length in a local variable:
static void Reverse3<T>(T[] xs)
{
int len = xs.Length;
for (int i = 0; i < len / 2; i++)
{
T x = xs[i];
xs[i] = xs[len - 1 - i];
xs[len - 1 - i] = x;
}
}
This does actually result in the generation of different IL code, however IL generation is only part of the story. The difference in execution time between these implementations is negligible. The reason is that the IL code is just-in-time (JIT) compiled to machine code before execution and this compilation step will apply further optimizations.
Premature optimization is wrong on so many levels:
- the optimization was probably unnecessary anyway
- code can become less readable for no tangible benefit
- you’re double guessing 2 compilation steps
- you’re probably not even considering high level optimizations
Pareto principle
The Sad Tragedy of Micro-Optimization Theater
Micro-Optimization and Meatballs
Micro-optimization tips to increase performance