Haskellでのパフォーマンスについて推論するのに適したタイミングはいつですか？

サイモンペイトンジョーンズ自身は、厳密でないセマンティクスのため、Haskellでのパフォーマンスについての推論が難しいことを認識しています。

Haskellで重要なプロジェクトをまだ書いていないので、疑問に思います。プロジェクトの最初（基本的なデータ構造とIOライブラリを選択するとき）にのみパフォーマンスについて推論できますか。問題が発生したときはいつでも、プロファイラーで処理しますか？

別の言い方をすれば、パフォーマンスの問題があるときにパフォーマンスへの対処を延期することは可能ですか（つまり、それほど痛くない）、またはGHCがコードを実行する方法を予測することを学ぶ必要があります（例：厳密性アナライザーが決定するものを推測する） ）？

その他の回答は、パフォーマンスの推論に関する幅広いアドバイスを提供します。この回答は、厳密ではないセマンティクスを具体的に扱っています。

怠惰はパフォーマンスを推論することを難しくしますが、あなたが考えるほど複雑ではありません。怠惰は状況によっては非常に便利ですが、ほとんどの場合、遅延言語は厳密な言語が使用されるのと同じ方法で使用されます。したがって、厳密な言語のパフォーマンス推論は、遅延のある言語に（いくつかの調整を加えて）適用できます。

時間の複雑さに関して、熱心な評価は遅延評価よりも厳密に多くの作業を行います。ほとんどの場合、どちらの方法でも同じ結果が得られます。（より正確には、熱心な評価でエラーが発生しない場合は、遅延評価と同じ結果が生成されます。）したがって、Haskellプログラムの時間の複雑さを推測するために、熱心に評価するふりをすることができます。遅延が問題となるまれな状況では、この見積もりは高すぎるため、下方修正する必要があります。

遅延評価では、熱心な評価よりも時間の複雑さが低くなりますが、スペースの複雑さ、つまりスペースリークが発生することがあります。厳密な注釈を追加してプログラムをより熱心に実行させることにより、スペースの複雑さを修正できます。プロファイリングツールは、スペースリークの原因を追跡するのに非常に優れています。重大度に応じて、これを正当性デバッグまたはパフォーマンスデバッグのいずれかに分類します。

コーディングする前に大きなものを最適化し、完了したら小さなことを最適化します。

たとえば、コーディングを開始する前に、次のことについて考える必要があります。

• 使用するライブラリ/フレームワークはまあまあ高速ですか？
• データ構造をシンプルに保つようにしてください。
• アルゴリズムと設計パターンをできるだけシンプルに保つようにしてください。
• 私が使っている言語はどれくらい速いですか？

...等々。

次に、コードがほとんど完成したら、どの組み込み関数がより高速であるかなど、コードのその領域を書き換えてより効率的にするかどうかなどについて考えます。

これはどの言語にも当てはまりますが、実際には、作成するソフトウェアの種類によって異なります。Haskellは汎用言語であるため、おそらく（間違っている場合は修正してください）非常に高速である必要のあるものは何も作成していません。その場合は、低レベルの言語を使用する必要があります。速度が問題であるが、低水準言語を使用する必要があるほど十分でない場合は、上記に基づいてパフォーマンスを最適化する必要があります。

もちろん、人によってやり方は異なります。したがって、個人的な経験から、状況に応じて異なる方法で行うべきだと思われる場合は、おそらくそうするべきです。

ダイナミックの答えに追加したいと思います：

• コードをモジュール化し、疎結合にします。
• モジュールの実装の詳細を非表示にします。

開発の後半でコードのボトルネックが何であるかを理解すると、プロジェクト全体をリファクタリングするのは非常に困難になります。コードが適切に構造化されていると、ボトルネックが見つけやすくなり、最適化/修正が容易になります。