5 ms·

> Lazy computation has its disadvantages. Still, impressive gain. After reading the article I don't see anything about lazy evaluation. What am I missing?

mcherm 14y ago
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. It's similar to moving something from runtime to compiletime (although those distinctions don't quite apply).
- icarus127 14y ago
  Ah, that was exactly how I read it. Basically what Yesod uses template Haskell for in a variety of cases.
- SilasX 14y ago
  >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 14y ago
    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 14y ago
      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 14y ago
    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").

mcherm 14y ago

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. It's similar to moving something from runtime to compiletime (although those distinctions don't quite apply).

icarus127 14y ago
Ah, that was exactly how I read it. Basically what Yesod uses template Haskell for in a variety of cases.
SilasX 14y ago
>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 14y ago
  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 14y ago
    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 14y ago
  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").