多くの場合、開発者は問題を解決するための 2 つの方法のいずれかを選択する必要があります。たとえば、C ベースの言語では、数値を 2 で乗算する方法が 2 つあります。
int SimpleMultiplyBy2(int x)
{
return x * 2;
}
と
int FastMultiplyBy2(int x)
{
return x << 1;
}
最初のバージョンは、技術者と非技術者の両方にとってより簡単に理解できますが、ビットシフトは乗算よりも簡単な操作であるため、2 番目のバージョンの方がパフォーマンスが向上する可能性があります。(ここでは、コンパイラのオプティマイザがこれを検出して最適化しないと仮定しましょう。ただし、これも考慮事項です)。
開発者として、最初の試みとしてどちらが良いでしょうか?
あなたは1つ逃しました。
最初にコードの正確さを確認し、次にわかりやすくします (もちろん、この 2 つはしばしば関連しています!)。最後に、実際に必要であるという実際の経験的証拠がある場合にのみ、最適化を検討できます。時期尚早の最適化は本当に悪です。最適化は、ほとんどの場合、時間、明確さ、保守性を犠牲にします。価値のあるものを購入していることを確認したほうがよいでしょう。
優れたアルゴリズムは、ほとんどの場合、ローカライズされたチューニングよりも優れていることに注意してください。正しく、明確で、高速なコードを作成できない理由はありません。ただし、「高速」に焦点を合わせてそこにたどり着くことができれば、不当に幸運になるでしょう。
IMO は、パフォーマンスが測定され、より高速なバージョンが必要になるまで、最初に明らかに読み取り可能なバージョンです。
ドン・クヌースから受け取ってください
時期尚早の最適化は、プログラミングにおけるすべての悪 (または少なくともその大部分) の根源です。
可読性 100%
コンパイラが "x*2" => "x <<1" 最適化を実行できない場合は、新しいコンパイラを入手してください。
また、プログラムの時間の 99.9% が、ユーザー入力の待機、データベース クエリの待機、およびネットワーク応答の待機に費やされていることも忘れないでください。20億回の倍数を行わない限り、目立たないでしょう。
確かな読みやすさ。誰かが文句を言わない限り、速度を気にする必要はありません
読みやすさ。
パフォーマンスのコーディングには、独自の一連の課題があります。ジョセフ・M・ニューカマーはよく言った
最適化は、重要な場合にのみ重要です。重要な場合は非常に重要ですが、重要であることがわかるまで、多くの時間を無駄にしないでください。重要だとわかっていても、どこが重要なのかを知る必要があります。パフォーマンス データがなければ、何を最適化すればよいか分からず、間違ったものを最適化する可能性があります。
結果はわかりにくく、書きにくく、デバッグしにくく、問題を解決しないコードを維持するのが難しくなります。したがって、(a) ソフトウェア開発とソフトウェア保守のコストが増加すること、および (b) パフォーマンスにまったく影響がないことの 2 つの欠点があります。
あなたの例では、99.9999% のコンパイラが両方のケースで同じコードを生成します。これは私の一般的なルールを示しています。最初に読みやすさと保守性のために書き、必要な場合にのみ最適化してください。
読みやすさ。最適化のタイミングは、ベータ テストの段階です。そうしないと、何に時間を費やす必要があるのか 本当にわかりません。
私はまず読みやすさを重視します。最近のような最適化された言語と大量にロードされたマシンを使用すると、読み取り可能な方法で記述したコードのほとんどが適切に実行されるという事実を考慮してください。
いくつかの非常にまれなシナリオでは、パフォーマンスのボトルネックが発生することがかなり確実であり (過去の悪い経験が原因である可能性があります)、パフォーマンスを大幅に向上させる奇妙なトリックを見つけることができました。それ。ただし、そのコード スニペットは非常に適切にコメントする必要があります。これにより、読みやすくなります。
この議論で見落とされがちな要因は、プログラマーが読みにくいコードをナビゲートし、理解し、変更するのに余分な時間がかかることです。プログラマーの時間が 1 時間あたり 100 ドル以上かかることを考えると、これは非常に現実的なコストです。
パフォーマンスの向上は、開発におけるこの直接的な追加コストによって打ち消されます。
そこに説明付きのコメントを入れると、読みやすく高速になります。
それは、プロジェクトの種類と、パフォーマンスがどれほど重要かによって大きく異なります。3D ゲームを構築している場合、通常、途中で追加したい一般的な最適化が多数あります。そうしない理由はありません (ただ、早い段階で夢中になりすぎないでください)。しかし、何かトリッキーなことをしている場合は、コメントして、それを見ている人がどのように、そしてなぜトリッキーなのかがわかるようにします。
答えは文脈によって異なります。たとえば、デバイス ドライバー プログラミングやゲーム開発では、2 番目の形式が許容されるイディオムです。ビジネス アプリケーションでは、それほど多くはありません。
最善の策は、コード (または同様の成功したアプリケーション) を調べて、他の開発者がどのようにそれを行っているかを確認することです。
両方。コードは両方のバランスを取る必要があります。読みやすさとパフォーマンス。いずれかを無視すると、プロジェクトの ROI が台無しになるため、最終的に上司にとって重要なのは ROI だけです。
可読性が悪いと保守性が低下し、保守により多くのリソースが費やされ、ROI が低下します。
パフォーマンスが悪いと、投資と顧客ベースが減少し、ROI が低下します。
<< を使用すると、マイクロ最適化が行われます。したがって、Hoare の (Knuts ではない) ルールは次のとおりです。
時期尚早の最適化は諸悪の根源です。
が適用され、最初はより読みやすいバージョンを使用する必要があります。
これは私見のルールであり、スケーリングやパフォーマンスが決して高くないソフトウェアを設計する言い訳として悪用されることがよくあります。
可読性がなければ、本当に必要なときにパフォーマンスの改善を得ることが非常に難しくなります。
プログラムに問題がある場合にのみパフォーマンスを改善する必要があります。この構文よりもボトルネックになる場所がたくさんあります。<< で 1ns の改善を押しつぶしているが、その 10 分の IO 時間を無視したとします。
また、読みやすさに関しては、プロのプログラマーはコンピューター サイエンスの用語を読んで理解できる必要があります。たとえば、putThisJobInWorkQueue と言う必要はなく、メソッド enqueue に名前を付けることができます。
コードベースが大きくなるほど、可読性が重要になります。いくつかの小さな関数を理解しようとすることは、それほど悪くありません。(特に、この例のメソッド名が手がかりを与えてくれるので。) コーディングをやめたばかりの孤独な天才によって書かれた、いくつかの壮大なコードにはあまり適していません。あなたのために書いたのに、あなたはそれを決して理解することはありません。
コードの可読性が心配な場合は、遠慮なくコメントを追加して、何を、なぜこれを行っているかを思い出してください。
ボトルネックがわからない場合、最適化しても意味がありません。関数を信じられないほど効率的に (通常はある程度読みやすさを犠牲にして) 作成したために、コードのその部分がほとんど実行されなかったり、いじり回したビットを保存するよりも多くの時間をディスクやデータベースにヒットさせたりしていることに気付くかもしれません。したがって、測定するものがあるまでマイクロ最適化することはできません。ただし、アーキテクチャ全体を設計するときは、速度とわかりやすさの両方に注意する必要があります。どちらも大きな影響を与える可能性があり、変更が困難になる可能性があるためです (コーディング スタイルと方法論によって異なります)。
読みやすさは最初のターゲットです。
1970 年代に陸軍は、当時の「新しい」ソフトウェア開発手法 (トップダウン設計、構造化プログラミング、チーフ プログラマー チームなど) のいくつかをテストして、統計的に有意な違いを生み出したのはどれかを判断しました。
発達に統計的に有意な違いをもたらした唯一のテクニックは...
プログラム コードに空白行を追加する。
これらの事前構造化された、オブジェクト指向以前のコードの可読性の向上は、これらの研究で生産性を向上させた唯一の手法でした。
==============
最適化は、プロジェクト全体が単体テストされ、インストルメンテーションの準備ができている場合にのみ対処する必要があります。コードをどこで最適化する必要があるかはわかりません。
1970 年代後半の Kernigan と Plauger の画期的な本で、SOFTWARE TOOLS (1976) と SOFTWARE TOOLS IN PASCAL (1981) は、トップダウン デザインを使用して構造化されたプログラムを作成する方法を示しました。彼らは、エディタ、検索ツール、コード プリプロセッサなどのテキスト処理プログラムを作成しました。
完成したテキスト整形関数が INSTRUMENTED されたとき、処理時間のほとんどが、テキストの入力と出力を実行する 3 つのルーチンで費やされていることがわかりました (元の本では、io 関数が時間の 89% を占めていました。Pascal の本では、これらの関数は55％消費！）
彼らはこれらの 3 つのルーチンを最適化することができ、合理的で管理しやすい開発時間とコストでパフォーマンスを向上させるという結果を生み出しました。
私はグーグルで働いていないので、邪悪なオプションを選びます。（最適化）
Jon Bentley の「Programming Pearls」の第 6 章で、6 つの異なる設計レベルで最適化することにより、1 つのシステムが 400 倍高速化した方法について説明しています。これら 6 つの設計レベルでパフォーマンスを気にしないことで、現代の実装者はプログラムで 2 ～ 3 桁の速度低下を容易に達成できると私は信じています。
読みやすさ第一。しかし、読みやすさだけでなく、特にデータ構造の点でシンプルです。
視覚分析プログラムを行っている学生のことを思い出しましたが、なぜそんなに遅いのか理解できませんでした。彼は単に優れたプログラミングの実践に従っただけです。各ピクセルはオブジェクトであり、隣接するピクセルにメッセージを送信することで機能しました...
これをチェックしてください
ほとんどの人が答えで言ったように、私は読みやすさを好みます。私が実行している 100 のプロジェクトのうち 99 には、厳しい応答時間の要件がないため、簡単な選択です。
コーディングを始める前に、すでに答えを知っているはずです。一部のプロジェクトには、「タスク X を Y (ミリ) 秒で実行できる必要がある」など、特定のパフォーマンス要件があります。その場合は、取り組むべき目標があり、いつ最適化する必要があるかどうかがわかります。(うまくいけば) これは、コードを書くときではなく、プロジェクトの要件の段階で決定されます。
読みやすさと後で最適化する機能は、適切なソフトウェア設計の結果です。ソフトウェアが適切に設計されている場合、システムの他の部分を壊すことなく、ソフトウェアの一部を分離し、必要に応じて書き直すことができるはずです。その上、私が遭遇したほとんどの真の最適化ケース (いくつかの実際の低レベルのトリックは無視しますが、それらは偶発的です) は、あるアルゴリズムから別のアルゴリズムに変更するか、ディスク/ネットワークではなくメモリにデータをキャッシュすることです。
ソフトウェアのコストの約 70% が保守にかかると推定されています。可読性により、システムの保守が容易になり、その結果、ソフトウェアの寿命全体のコストが削減されます。
可読性よりもパフォーマンスが重要な場合がありますが、そのようなケースはほとんどありません。
可読性を犠牲にする前に、「私 (またはあなたの会社) は、これを行うことでシステムに追加される余分なコストに対処する準備ができているか?」と考えてください。
常に最大限に最適化する必要があります。パフォーマンスは常に重要です。 今日ブロートウェアが存在する理由は、ほとんどのプログラマーが最適化作業を行いたくないからです。
そうは言っても、洗練されたコーディングで明確にする必要がある場合は、いつでもコメントを入れることができます。
ビットシフト対乗算は、ほとんど何も得られない些細な最適化です。そして、指摘されているように、コンパイラがそれを行う必要があります。それ以外は、この命令が実行される CPU と同様に、とにかくゲインは無視できます。
一方、本格的な計算を実行する必要がある場合は、適切なデータ構造が必要になります。しかし、問題が複雑な場合は、それについて調べることが解決策の一部です。例として、1000000 個の並べ替えられていないオブジェクトの配列で ID 番号を検索することを検討してください。次に、バイナリ ツリーまたはハッシュ マップの使用を再検討します。
しかし、 n << C のような最適化は、通常は無視でき、いつでも簡単に変更できます。コードを読みやすくすることはできません。
解決する必要があるタスクによって異なります。通常は可読性の方が重要ですが、最初にパフォーマンスを考慮する必要があるタスクがいくつかあります。また、すべてが完全に機能した後、プロファイリングと最適化に 1 日または 1 日を費やすことはできません。最適化自体は、コードの十分な部分を最初から書き直す必要があるからです。しかし、今日では一般的ではありません。
1時間のプロセッサ時間はどれくらいの費用がかかりますか？
プログラマーの1時間の時間はどれくらいの費用がかかりますか？
読みやすさ。これにより、他の人 (または後で自分自身) が、何を達成しようとしているのかを判断できるようになります。後でパフォーマンスについて心配する必要があることがわかった場合は、読みやすさがパフォーマンスの達成に役立ちます。
また、読みやすさに集中することで、実際にはコードが単純になり、複雑なコードよりもパフォーマンスが向上する可能性が高いと思います。
IMHO両方のことは何の関係もありません。これはパフォーマンスや読みやすさよりも重要であるため、最初に機能するコードを選択する必要があります。読みやすさについて: コードは常に読みやすいものにする必要があります。
しかし、なぜコードを読みやすくすると同時に優れたパフォーマンスを提供できないのか、私にはわかりません。あなたの例では、2番目のバージョンは最初のバージョンと同じくらい読みやすいです。それについて読みにくいのは何ですか？左にシフトすることは 2 の累乗を掛けることと同じであり、右にシフトすることは 2 の累乗で割ることと同じであることをプログラマーが知らない場合は、一般的な読みやすさよりもはるかに基本的な問題が発生します。
優先順位は読みやすさでなければなりません。次に、メンテナーが何かが標準ではない理由を理解できるように、十分にコメントされている場合、パフォーマンスが向上します。
「パフォーマンスは常に重要」というのは正しくありません。I/O バウンドの場合、乗算速度は重要ではありません。
「今日ブロートウェアが存在する理由は、ほとんどのプログラマーが最適化作業を行いたくないからです」と誰かが言いましたが、それは確かに真実です。これらを処理するコンパイラがあります。
最近のコンパイラは、そのアーキテクチャに適していれば、に変換x*2されます。x<<1これは、コンパイラーがプログラマーよりも賢い場合です。
ほとんどの場合、読みやすさがはるかに重要であるという世界のほとんどに同意します。コンピューターは想像以上に高速であり、さらに高速化する一方です。コンパイラーはマイクロ最適化を行います。ボトルネックがどこにあるかを見つけたら、後でボトルネックを最適化できます。
一方で、場合によっては、たとえば深刻な計算処理やその他の非対話的で計算量の多いタスクを実行する小さなプログラムを作成している場合、パフォーマンスの目標を設定して高レベルの設計上の決定を行う必要がある場合があります。念頭に置いて。これらのケースで遅い部分を後で最適化しようとすると、基本的にコードの大部分を書き直すことになります。たとえば、小さなクラスなどで物事を適切にカプセル化しようとすることもできますが、パフォーマンスが非常に優先される場合は、たとえばメモリ割り当てをあまり実行しない、十分に考慮されていない設計で妥協する必要がある場合があります。 .
最初に読みやすく書きますが、読者はプログラマーであることを期待してください。彼または彼女のソルトに値するプログラマーは、乗算とビットシフトの違いを知っているか、適切に使用されている三項演算子を読むことができ、複雑なアルゴリズムを調べて理解できる必要があります (あなたは自分のコードにコメントしていますよね? ）など
もちろん、初期の過度の最適化は、後でリファクタリングが必要になったときに問題を引き起こすのに非常に役立ちますが、個々のメソッド、コード ブロック、またはステートメントの最適化には実際には当てはまりません。
私は読みやすさのために行くと思います。
しかし、与えられた例では、関数の名前が関数で何が起こっているかを正確に示しているため、2番目のバージョンはすでに十分に読みやすいと思います。
関数が何をするかを教えてくれる関数が常にあるとしたら...
ソフトウェアをリリースする場合は、プロセスではなく、結果を気にする必要があります。
ユーザーはあなたのコードを読むつもりはなく、あなたのソフトウェアを使用するつもりであり、不必要に長い待ち時間にイライラしたくはありません。よくインデントされ、適切にコメントされたアプリケーションの実行が遅くなったり、大量のメモリを消費したりすると、彼らはあなたを嫌うでしょう。
要するに、自分ではなくユーザーのことを考えて、読みやすさよりもパフォーマンスを優先してください。
このルールの最も良い例の 1 つは、Quake ビデオ ゲームです。そのコードはよく構造化されておらず、読みにくいことがよくありますが、1995 ～ 1996 年の PC で非常に高いフレーム レートで数千のポリゴンをレンダリングできます。カーマックがパフォーマンスよりも可読性を優先した場合、Quake や、Call of Duty (Quake 3 エンジンから派生したもの) を含む他の多くのビデオ ゲームは存在しなかったでしょう。