When the only kind of procedures we knew how to write were non-recursive, we could count the number of terms and primitive operators in the static description of an expression and have an idea of how long the expression would run (how many Scheme evaluations, and ultimately, how many machine cycles). However, once we start writing recursive procedures, the actual (dynamic) number of execution steps can be much larger than the number of static, primitive operators---and harder to predict and understand. In fact, in day 3's lecture, we saw that recursion gave us the power to perform computations of unbounded size---computations whose size and length of execution time depend on the size of the input. The computations we saw last time had time and space requirements that increased linearly as the size of the input value increased, but that will not always be the case.
It's important to understand how a computation will unfold dynamically as it executes, how long it will run for a given input, and how much memory space it will require for a given input. For well designed programs, we can write down equations that tell us how long a program runs and how much space it will use in terms of its inputs or properties of its inputs. These equations are very useful in understanding how long programs will run when we have different, usually larger, input values or input sizes.
Any particular problem which we may wish to solve can usually be programmed in a number of different ways. However, not all implementations will take the same amount of time or require the same amount of computer memory (space). By understanding how each program runs as a function of the input size, we can determine which implementations will require the least amount of time and/or space for given inputs. This is a very important part of designing efficient procedures.