In and Out

Autocompilation

**Q: **I would like to understand the timing difference between the following two code samples. Slow version:

Fast version:

Is this due to autocompilation?

**A: **Robert Knapp (rknapp@wolfram.com) answers: The issue has to do with autocompilation, but is quite subtle. is basically equivalent to . With the second form, it is a bit easier to see why it cannot be autocompiled. Each time the inner Table is computed, needs to be evaluated to determine what the limit should be. Therefore the issue boils down to why it needs to be evaluated *each* time through the outer loop. Before evaluation, is just a symbol, so it could have any evaluation attached to it, for example, . In this example, the result of evaluating with only one would obviously be wrong. You might think it would be possible to evaluate with unset, but there are cases where that would be incorrect, for example, . This is, of course, pathological, but it is not too difficult to construct real cases that give incorrect or misleading values. It is very important that *Mathematica* be consistent, so we cannot do this. Thus, since cannot be known, except for specific values of , there is no way to autocompile the loop as a whole in a really efficient way. On the other hand, when you evaluate or put in literal numbers, everything is known, so compilation analysis can be done quite completely.