On the Efficiency of code Execution (2): The power of the compiler

In the last article, I mainly expressed the view that one of the keys to the efficiency of the program is the algorithm, and the choice and optimization of the algorithm, and whether more than one assignment is less than one judge of the relationship. On the choice of algorithm, I talked about its theoretical complexity, does not directly reflect the efficiency. Because in the actual use, the size of the data, features and so on will involve the actual effect of the algorithm. An algorithm with low time complexity does not mean high efficiency in any situation. This is one of the differences between "practical" and "theoretical". Now I'm going to talk about another thing that's more "real": the effect of compilers on program efficiency.

So let's take a look at this piece of code, assuming that there is a one-way linked list of integers, asking you to write a function to sum, how would you write it? If we use F #, the easiest way to implement it is recursively:

let　rec　sum　ls　=
　　 match　ls　with
　　 |　[]　->　0
　　 |　x　::　xs　->　x　+　(sum　xs)

This F # code uses pattern matching: if it is an empty list, the result is naturally equal to zero, otherwise the first element is added to the sum of the remaining elements. This code is obviously very simple, with a declarative approach to "express" the logic of the function, there is no redundant code. But you must have found that recursion is used in the implementation of this function, so the time complexity of this function is O (n) for a linked list of length n, and the space complexity is O (n)-The cost of space is on the call stack of the function. In general, recursion is always difficult to escape the accumulation of call stacks, so its space complexity is always difficult to do O (1) constant level. The stack of call stacks, so that the program in the implementation of access to the memory address span is increasing, easy to cause the program's local (locality) poor, poor performance--on the impact of local code, we will discuss the next article.

Of course, some friends may say, why should we use recursion? Is it OK to use a normal for or while loop and then keep accumulating? Of course, and in so doing, the space complexity is O (1), the time complexity is still O (n), but after the above description, we can know that its actual execution efficiency is better than the recursive way. However, For/while are both imperative programming and not suited to the "declarative" style of functional programming, so in practical applications we tend to write the sum function:

let　sum　ls　=
　　 let　rec　sum'　ls　acc　=
　　　　 match　ls　with
　　　　 |　[]　->　acc
　　　　 |　x　::　xs　->　sum'　xs　(acc　+　x)

　　 sum'　ls　0

This sum function defines an auxiliary function sum ', this auxiliary function will have one more parameter as "accumulator", in which the syntax of pattern matching is still used, and the value of the accumulator is returned directly when an empty array is encountered, otherwise the first element of the list is added to the accumulator, and then the sum ' auxiliary function is recursively called. Yes, it's still recursive. So does it look like the effect should be less different than the previous implementation?

What about the actual results? If you have the conditions, you might want to try it yourself-I'll post the sum ' function code from. NET Reflector to C #:

[Serializable]　
internal　class　sum'@9　:　OptimizedClosures.FSharpFunc<FSharpList<int>,　int,　int>
{
　　 public　override　int　Invoke(FSharpList<int>　ls,　int　acc)
　　 {
　　　　 while　(true)
　　　　 {
　　　　　　 FSharpList<int>　list　=　ls;
　　　　　　 if　(!(list　is　FSharpList<int>._Cons))
　　　　　　 {
　　　　　　　　 return　acc;
　　　　　　 }
　　　　　　 FSharpList<int>._Cons　cons　=　(FSharpList<int>._Cons)list;
　　　　　　 FSharpList<int>　xs　=　cons.get_Tail();
　　　　　　 int　x　=　cons.get_Head();
　　　　　　 acc　+=　x;
　　　　　　 ls　=　xs;
　　　　 }
　　 }
}