Когда отложенные вычисления не полезны?

Lazy loading resources involves a trip back and forth between the requester and the source for each load. In the case of NHibernate, this means a from the application to the database (which is often on a different server).

There is often overhead associated with each trip (there certainly is for NHibernate or any other DB query).

If you know that you will need all or a substantial portion of the data, you are better off pulling it in one go and only incurring the overhead once.

A classic example is when you need to pull back a list of objects to populate a combo box (often these will be configuration objects). Lazy loading would go back to the database each time you added a list member to the combo box. Since you're putting the entire list into the combo box, you would incur lots of extra overhead to lazy fetch each object.

Lazy evaluation is not useful in situations where performance is critical and a value must always be evaluated. In these cases you are better off just evaluating the value and being done with it, because the overhead of lazy evaluation will be wasted.

It can also be a problem with the user experience of your program. People will happily wait for 5 seconds when a banner is displayed on the screen during app loading, but they despise to have to wait 0.25 seconds when they're typing in something in a textbox. If the amount of time it takes to load all your data eagerly is not that long, you may consider doing it at some point in the workflow where people accept a delay (such as app loading, window pop up, button presses).

Ленивое вычисление бесполезно, если вы не хотите сохранять значение, просто используйте его. Но это зависит от реализации ленивого оценщика. Некоторые системы (например, Haskell) могут определить, будет ли значение использоваться снова. Некоторые другие не могут и могут вызвать утечки.

Ленивая оценка не полезна, когда оценка может иметь побочные эффекты. Это единственная причина, и именно поэтому она есть только в чисто функциональных языках. Если выражения могут иметь побочные эффекты, которые должны происходить в определенном порядке, вы не можете его использовать.

Кроме того, ленивая оценка только повышает производительность, это ее основная цель. Вот почему некоторые языки запрещают побочные эффекты, чтобы получить ленивую оценку для этого компромисса, еще один приятный эффект - управляющие структуры могут быть регулярными функциями.

Один пример лени, вызывающего странные проблемы (случилось со мной сегодня в Haskell):

import System.IO

main = do
    content <- readFile "foo.txt"
    writeFile "foo.txt" content 

При компиляции и выполнении возникает следующая ошибка:

foo.txt: openFile: resource busy (file is locked)

Что Думал, подойдет: Откройте файл foo.txt, прочтите содержимое, снова закройте его. Затем откройте его для записи, напишите содержание и снова закройте.

Что он на самом деле сделал: «Ах, немного содержания. Я, наверное, прочту его позже, когда он нам действительно понадобится». Затем откройте "foo.txt" для записи. Начни писать контент ... хорошо, теперь нам нужен контент. Откройте foo.txt для чтения - бац!

Я знаю, что это легко исправить, но это сложно найти, если вы не знаете, где искать.

Вы не можете выполнить редукцию (например, сложение) на входных данных в постоянном пространстве с ленивой оценкой, поскольку отложенная оценка каждого шага редукции приводит к линейной сложности пространства. Вместо этого вы должны принудительно оценивать результат каждого шага редукции, чтобы сохранить постоянное использование пространства.

Например, хэширование файла на языке Haskell. Возможно, вы руководствуетесь благими намерениями и лениво читаете входной файл кусок за куском, добавляя каждый кусок в дайджест, но за вашей спиной Haskell на самом деле создает транк для каждого куска, который вы добавляете в дайджест, оставляя весь файл в памяти в этих транках до тех пор, пока результирующий дайджест не будет фактически оценен. Ай!

См. последний комментарий здесь: Ленивый ввод-вывод в Haskell и закрытие файлов