ドナルド・クヌースは「時期尚早の最適化はすべての悪の根源である」と言っており、私はそのことを徐々に信じています。
では、アプリケーションを作成するときは、パフォーマンスの問題を気にせずに、パフォーマンスの低下に耐えられなくなるまで、機能の完了に集中する必要があると言えますか？
間違ったパターンを何度も使用してアプリケーションの速度が低下すると、結果として問題の修正にかなりの時間がかかる可能性があります。広く使用する前に、パターンのパフォーマンスをテストする必要がありますか？
私が言及したパターンは、Linqまたはforループの使用、、、、または、の使用、破棄、Delegate.BeginInvokeまたは単に無視することなどを指す場合があります。Parallel.ForTask<T>IDisposable
あらゆる参考資料を歓迎します。
時期尚早の最適化に関するKnuthの引用の精神に同意します。これは、開発の初期段階でコードが過度に複雑になり、扱いにくくなり、コードの品質とプロジェクトの完了に必要な時間の両方に影響を与える可能性があるためです。
私があなたの投稿について持っている2つの懸念：
関数/アルゴリズムが理論的にスケーリング/実行して要件を満たすことができるかどうかを理解する必要があります（たとえば、ソリューションの複雑さ-> http://en.wikipedia.org/wiki/Analysis_of_algorithms）
あなたが言及するパターンは実際には具体的な実装項目であり、そのうちのいくつかだけがパフォーマンスに関連しています。
パフォーマンスを気にせずにコーディングしないでください。
コードがより複雑になるまで（並列など）、パフォーマンスのためのコード。
しかし、C＃5.0では、並列処理でさえ複雑ではありません。
いくつかの呼び出しがある場合は、最適化する必要があると思われる場合は、そのために設計します。
最適化によってメソッドへのインターフェースが変更されないようにコードを設計します。
速度、メモリ、同時実行性（サーバーアプリの場合）、信頼性、セキュリティ、およびサポートがあります。
多くの場合、クリーンなコードが最良のコードです。
パフォーマンスに問題があることがわかるまで気が狂うことはありませんが、だらしないことはありません。
SOに関する別の質問に答える際に、私はその人にDataTableは必要なく、DataReaderはより少ないメモリでより高速になると言いました。彼らの反応は、それでも私が気にしない1/2秒で実行されるというものでした。私にとって、それはずさんなコードです。
@JonhSanders「コードがより複雑になるまでのパフォーマンスのためのコード」がバグまたは不完全な原因になることに同意しません。私にとって、パフォーマンスのコーディングは最適化と同じではありません。最初に、パフォーマンスのためにコーディングしたコードを破棄する以外は何でも渡します。エキゾチックなものはなく、ベストプラクティスだけです。戻って最適化する必要がある可能性のある潜在的なホットスポットを見つけた場合は、最適化を念頭に置いて記述します。PS私は質問を閉じることに同意します。