No computer program can be truly optimized. Because of the complexity of optimization, it is impossible to tell if one representation is truly "optimal." Optimization is a misnomer. But it remains a useful practice in the real world.
This article describes why optimization is a misnomer in computer programs.
One of the major problems with many of the benchmarks on Dot Net Perls is that they isolate one problem. In an actual software project, they would be just one part of a larger solution. Because of this, optimizations tend to de-emphasize the problems associated with memory usage and over-emphasize execution speed.
Program that uses lookup table [Version A] [C#]
class Program
{
static void Main()
{
int[] lookup = new int[3];
lookup[0] = 5;
lookup[1] = 7;
lookup[2] = 9;
System.Console.WriteLine(lookup[int.Parse("1")]);
}
}
Program that uses switch [Version B] [C#]
class Program
{
static void Main()
{
switch (int.Parse("1"))
{
case 0:
System.Console.WriteLine("5");
break;
case 1:
System.Console.WriteLine("7");
break;
case 2:
System.Console.WriteLine("9");
break;
}
}
}
Output of either program
7Explanation. You can see that the first program (Program A) uses a lookup table to print the value 7 from the index 1. The second program (Program B) uses a switch statement to print the value "7" from the index 1.
Which is optimal? There is a trade-off between using more memory for a lookup table and using possibly slower code for a switch statement. On Dot Net Perls, the lookup table might be chosen as the speed champion because a single array access is likely faster than a large switch statement.
Memory pressure. But in many programs, there will occur thousands of allocations on the managed heap. Adding another allocation for the lookup table will add memory pressure. This will trigger more garbage collections, which will cause slowdowns in other parts of the system that might be important.
Conclusion. So you can see that the lookup table, which might execute faster, could be a worse choice in many (if not most) programs. After spending time optimizing a method to use a lookup table, you could be left with a system that performs worse.
Compiler theory, and much of optimization in programming, is undecidable. It's really impossible to tell for sure (or to prove) that one version is "optimized." The one way you could improve the situation is by testing many different computer configurations, programs and scenarios.
Further complexity into optimization is introduced by people issues. If a system becomes too complex, it is unwieldy. This can have a much greater impact on a system than a single slow method. But while clear code is an ideal, it can often be terribly slow. A careful balance is demanded.
Programs guard huge amounts of hidden complexity. As formulaic encodings of our thoughts, they can be staggeringly complex and also deceptively simple. Even as programs can never be optimized, our fragile attempts at optimization yield tremendous advances.
Algorithms