> However, we realized that a lot of the transformations could be done at load time and preprocessed to an intermediate representation.
Lazy computation has its disadvantages. Still, impressive gain.
After reading the article I don't see anything about lazy evaluation. What am I missing?
It's similar to moving something from runtime to compiletime (although those distinctions don't quite apply).
Lazy evaluation: waiting until a computation needs to be done to perform it.
Problem here: it was inefficient to do a particular computation at the very moment before it was needed.
So, how is this not a lazy evaluation problem?
Unless I am mistaken, they didn't change the template language evaluation strategy from call-by-name to call-by-value.
They did change the implementation from an interpreter to a compiler, though.
* A space leak: The deferred computation holds lots of data alive for when it will be needed, whereas computing it would reduce all that data into a small result.
* A latency problem (sometimes called a "time leak") where we may idle around for a while, and only when some value is desperately needed, start computing it. We could preemptively compute the result to hide its latency.
These were not the problem here. The problem here was that part of the computation of the result is redone each time.
Sharing parts of the computation between the invocations was not trivial, and to do this, they found it easier to move the computation to the template loading time ("compile time").