[SilasX]

>I don't think you ARE missing anything. From my reading, the gains are obtained by pre-computing the string concatenation a single time (rather than while rendering) for all cases in which it can be.

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?

[dons]

Laziness is a specific property of how variable binding and application works in a language, which is not at issue here.

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.

[lrem]

I had the same line of thinking as SilasX. Conceptually, the change is that instead of deferring work to the last moment available, it is now done immediately. This is the very difference between lazy and eager computation. As I'm not a Haskeller, I didn't immediately realize the strong connotation with language features. Sorry for the confusion.

[Peaker]

Lazy evaluation implies that you keep the result for re-use later if it is shared between multiple users. So if laziness causes performance problems, it is generally:

* 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").