私は現在、「パフォーマンス上の理由」のために、お粗末なテストや保守が不可能なコードを変更することに恐怖を感じているクライアントのために働いています。多くの誤解が蔓延していることは明らかであり、その理由は理解されておらず、単に盲目的な信念に従っているだけです。
私が遭遇したそのようなアンチパターンの 1 つは、できるだけ多くのクラスを封印された内部としてマークする必要があることです...
*再編集: すべてを封印された内部 (C#) としてマークするのは時期尚早の最適化だと思います.*
人々が認識している、または遭遇する可能性のある他のパフォーマンスのアンチパターンにはどのようなものがあるのだろうか?
私が遭遇した最大のパフォーマンスのアンチパターンは次のとおりです。
パフォーマンス データを収集すると、特定のテクニックが成功したかどうかがわかります。そうしないと、まったく役に立たないアクティビティが発生します。何も変わっていないのに、パフォーマンスが向上したという「感覚」を誰かが持っているからです。
部屋の中の象: より良いアルゴリズムではなく、実装レベルのマイクロ最適化に焦点を当てています。
変数の再利用。
私は宣言で数サイクルを節約し、メモリフットプリントを削減していると考えて、これを常に行っていました。これらの節約は、特にコード ブロックを移動することになり、開始値に関する仮定が変更された場合に、コードをデバッグするのがどれほど手に負えないものになるかと比較すると、非常に価値がありました。
時期尚早のパフォーマンスの最適化が頭に浮かびます。私はどうしてもパフォーマンスの最適化を避ける傾向があり、それが必要だと判断した場合は、問題を同僚に何度か回して、わかりにくい最適化を適切な場所に配置するようにしています。
関数呼び出しのペナルティを回避するために、関数の代わりに#definesを使用します。私は、定義の拡張が巨大で本当に遅いコードを生成することが判明したコードを見てきました。もちろん、デバッグも不可能でした。インライン関数はこれを行う方法ですが、同様に注意して使用する必要があります。
独立したテストがswitchステートメントで使用できる単語のビットに変換されたコードを見てきました。切り替えは非常に高速ですが、一連の独立したテストをビットマスクに変えて、256の最適化された特殊なケースを書き始めると、パフォーマンスが向上することを証明する非常に優れたベンチマークが得られます。メンテナンスの観点からは本当に苦痛であり、さまざまなテストを個別に処理すると、コードがはるかに小さくなり、パフォーマンスにとっても重要になります。
私が遭遇したのは、Rulas のコメントで言及された Jeff Atwood の記事の逆のような、十分に高速にしようとして、深刻に壊れたコードにハードウェアを投入することでした。より高速なハードウェアで実行することによって基本的で正しいアルゴリズムを使用する並べ替えを高速化することと、最適化されたアルゴリズムを使用することの違いについて話しているのではありません。O(n log n) アルゴリズムが標準ライブラリにある場合、明らかに正しくない自作の O(n^3) アルゴリズムを使用することについて話しているのです。プログラマーが標準ライブラリーに何が入っているかを知らないため、ハンド・コーディング・ルーチンのようなものもあります。それはとてもイライラします。
使ってもらうためだけにデザインパターンを使う。
ジュリアンバーチはかつて私に言った：
「はい。しかし、開発者がアプリケーションを実行するのに費やした時間を埋め合わせるのに、実際にアプリケーションを実行するのに何年かかりますか？」
彼は、実装に一定の時間がかかる最適化によって、各トランザクション中に節約された累積時間を参照していました。
古い賢人からの賢明な言葉...ファンキーな最適化を行うことを検討するとき、私はしばしばこのアドバイスを思い浮かべます。現在の状態でコードを処理するために開発者が費やしている時間と、ユーザーが節約している時間を考慮することで、同じ概念をもう少し拡張できます。必要に応じて、開発者とユーザーの時間単価で時間を重み付けすることもできます。
もちろん、測定が不可能な場合もあります。たとえば、eコマースアプリケーションの応答に1秒長くかかる場合、その1秒間に退屈するユーザーからわずかな割合のお金を失うことになります。その1秒を補うには、最適化されたコードを実装して維持する必要があります。最適化は粗利益にプラスの影響を与え、純利益にマイナスの影響を与えるため、バランスを取るのがはるかに困難になります。あなたは試すことができます-良い統計で。
コードの作成中にリファクタリングや最適化を行わないでください。コードを完成させる前にコードを最適化しようとしないことが非常に重要です。
明確なプログラム構造の欠如は、それらすべての中で最大のコードの罪です。高速であると信じられている複雑なロジックは、ほとんど高速ではありません。
プログラミング言語の悪用。PLSnakish 1.4 ではより高速であるという理由だけで、if/else の代わりに例外処理を使用するようなものです。何だと思う？PLSnakish 1.8 では言語の保守担当者が問題を修正し、現在は if/else になっているため、コードを難読化し、実行速度を大幅に低下させたため、2 年後にコードを保守している誰かがあなたに腹を立てる可能性があります。例外処理のトリックを使用するよりも 10 倍高速です。プログラミング言語とフレームワークで作業してください!
一度に複数の変数を変更する。これは私を絶対に狂わせます！複数の項目が変更された場合、変更がシステムに与える影響をどのように判断できますか?
これに関連して、観察によって保証されていない変更を加えること。プロセスが CPU バウンドでないのに、なぜより高速な CPU を追加する必要があるのですか?
以前のクライアントから電話があり、アプリの高速化についてアドバイスを求められました。
彼は私が「Xをチェックし、次にYをチェックし、次にZをチェックする」、つまり専門家の推測を提供することを期待しているようでした。
私はあなたが問題を診断しなければならないと答えました。私の推測は他の人よりも間違っていることが少ないかもしれませんが、それでも間違っているので、がっかりします。
彼は理解していないと思います。
Michael A Jackson は、パフォーマンスを最適化するための 2 つのルールを示しています。
人々がパフォーマンスを心配している場合は、それを実現するように伝えてください。優れたパフォーマンスとは何か、それをどのようにテストしますか? 次に、コードが標準に達しない場合は、少なくともコード作成者とアプリケーション ユーザーが同意するものです。
硬直化したコードを書き直すことによるパフォーマンス以外のコスト (時間の浪費など) を懸念している場合は、見積もりを提示し、スケジュール内で実行できることを示してください。できると仮定します。
一部の開発者は、高速だが正しくないソリューションが、低速だが正しいソリューションよりも望ましい場合があると考えています。そのため、本番環境では「決して起こらない」または「問題にならない」さまざまな境界条件や状況を無視します。
これは決して良い考えではありません。ソリューションは常に「正しい」必要があります。
状況に応じて、「正しい」の定義を調整する必要がある場合があります。重要なことは、どのような条件に対しても結果を正確に把握/定義し、コードがそれらの結果を提供することです。
一般的な解決策。
特定のパターン/テクノロジーがある状況で優れたパフォーマンスを発揮するからといって、別の状況でも優れたパフォーマンスを発揮するとは限りません。
.Net での StringBuilder の過剰使用は、このよくある例です。
「金属に近い」スーパー リーン コードはエレガントなドメイン モデルよりもパフォーマンスが高いというのはよくある神話だと思います。
これは、DirectX の作成者/主任開発者によって明らかになったことであり、C# で c++ バージョンを書き直して大幅な改善を加えました。[ソースが必要]
(たとえば) C++ STL の push_back()、D の ~= などを使用して配列に追加します。配列の大きさが事前にわかっていて、事前に割り当てることができる場合。