過去数日間、私は主にパフォーマンスの側面で LazyEvaluation を調査しました。
さまざまな記事を読んでもよくわかりませんが、以下を含むごく少数の記事を読んでいます
これは、構文ツリーの評価を指します。構文ツリーを遅延して評価する場合 (つまり、それが表す値が必要な場合)、計算の前のステップ全体を実行する必要があります。これは遅延評価のオーバーヘッドです。ただし、2 つの利点があります。1)結果がまったく使用されない場合、不必要にツリーを評価しません。
たとえば、if構文を実装した JavaScript。
if(true)
{
//to evaluate
}
else
{
//not to evaluate
}
この通常のシナリオでは、パフォーマンスの問題はありません。
評価される場合は実行され、評価されない場合は構文ツリーで無視されます。
ただし、一部の再帰ループでは、たとえば、Tak 関数 AKA Tarai 関数
関数 tak(x,y,z){ return (x <= y) ? y : tak(tak(x-1, y, z), tak(y-1, z, x), tak(z-1, x, y)); }
JS の Eager Evaluation 戦略は関数 (引数) の必然性を評価するため、if - else - 評価されない制御が機能しなくなり、 tak 関数の評価ステップの数が爆発的に増加します。
Eager Evaluation (JS や他の言語の) のこの欠点に対して、Haskell はtakをそのまま問題なく評価でき、 lazy.jsなどの一部の JS ライブラリは、再帰的なリスト管理が必要な関数型プログラミングのような特定の領域で優れています。
無限リストは別として、これが LazyEvaluation のパフォーマンス上の利点の正確な理由であることを理解しています。私は正しいですか?