多くの場合、開発者は、問題を解決するための2つの可能な方法から選択する必要があります。1つは慣用的で読みやすい方法で、もう1つは直感的ではないがパフォーマンスが向上する可能性があります。たとえば、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億回の倍数を実行しない限り、それは目立たないでしょう。
あなたの与えられた例では、そこにあるコンパイラの99.9999％が両方の場合に同じコードを生成します。これは私の一般的なルールを示しています-最初に読みやすさと保守性のために書き、必要なときにだけ最適化してください。
読みやすさ。
パフォーマンスのコーディングには、独自の課題があります。ジョセフ・M・ニューカマーはよく言った
最適化は、重要な場合にのみ重要です。それが重要であるとき、それは非常に重要ですが、それが重要であることがわかるまで、それをするのに多くの時間を無駄にしないでください。それが重要であると知っていても、それがどこで重要であるかを知る必要があります。パフォーマンスデータがないと、何を最適化するかわからず、おそらく間違ったものを最適化することになります。
結果はあいまいで、書きにくく、デバッグしにくく、問題を解決しないコードを維持するのが難しくなります。したがって、（a）ソフトウェア開発とソフトウェア保守のコストが増加すること、および（b）パフォーマンスへの影響がまったくないことの2つの欠点があります。
コードの可読性が心配な場合は、コメントを追加して、何を、なぜこれを行っているのかを思い出してください。
常に最大限に最適化する必要があり、パフォーマンスは常に重要です。 今日私たちがブロートウェアを持っている理由は、ほとんどのプログラマーが最適化の仕事をしたくないからです。
そうは言っても、巧妙なコーディングで明確にする必要がある場所にはいつでもコメントを入れることができます。
ビットシフトと乗算は、ほとんど何も得られない簡単な最適化です。そして、指摘されているように、あなたのコンパイラはあなたのためにそれをするべきです。それ以外は、この命令が実行されるCPUと同様に、ゲインは無視できます。
一方、本格的な計算を実行する必要がある場合は、適切なデータ構造が必要になります。しかし、問題が複雑な場合は、それを見つけることが解決策の一部です。例として、1000000のソートされていないオブジェクトの配列でID番号を検索することを検討してください。次に、バイナリツリーまたはハッシュマップの使用を再検討します。
ただし、n << Cのような最適化は通常無視でき、いつでも変更するのは簡単です。コードを読みやすくすることはできません。
ソフトウェアのコストの約70％がメンテナンスに費やされていると推定されています。読みやすさにより、システムの保守が容易になるため、ソフトウェアの耐用年数にわたってコストが削減されます。
パフォーマンスが読みやすさよりも重要である場合があります。
読みやすさを犠牲にする前に、「私（またはあなたの会社）は、これを行うことによってシステムに追加する追加コストに対処する準備ができていますか？」と考えてください。
ほとんどの人が答えで言ったように、私は読みやすさを好みます。私が実行している100のプロジェクトのうち99は、厳しい応答時間の要件がないため、簡単に選択できます。
コーディングを始める前に、すでに答えを知っている必要があります。一部のプロジェクトには、「タスクXをY（ミリ）秒で実行できる必要がある」などの特定のパフォーマンス要件があります。その場合は、取り組む目標があり、最適化する必要があるかどうかがわかります。（うまくいけば）これは、コードを書くときではなく、プロジェクトの要件段階で決定されます。
読みやすさと後で最適化する機能は、適切なソフトウェア設計の結果です。ソフトウェアがサウンドデザインである場合、システムの他の部分を壊すことなく、ソフトウェアの一部を分離し、必要に応じてそれらを書き直すことができるはずです。その上、私が遭遇した最も真の最適化のケース（いくつかの実際の低レベルのトリックを無視して、それらは偶発的です）は、あるアルゴリズムから別のアルゴリズムに変更するか、ディスク/ネットワークではなくメモリにデータをキャッシュすることでした。
読みやすさが最初の目標です。
1970年代に、陸軍はソフトウェア開発の当時の「新しい」技術のいくつか（トップダウン設計、構造化プログラミング、チーフプログラマーチームなど）をテストして、統計的に有意な違いをもたらしたものを特定しました。
開発に統計的に有意な違いをもたらした唯一の手法は...
プログラムコードへの空白行の追加。
これらの事前構造化された事前オブジェクト指向コードの可読性の向上は、生産性を向上させたこれらの研究の唯一の手法でした。
==============
最適化は、プロジェクト全体が単体テストされ、計測の準備ができている場合にのみ対処する必要があります。コードを最適化する必要がある場所がわかりません。
1970年代後半のKerniganand Plaugerの画期的な本で、SOFTWARE TOOLS（1976）とSOFTWARE TOOLS IN PASCAL（1981）は、トップダウン設計を使用して構造化プログラムを作成する方法を示しました。彼らはテキスト処理プログラムを作成しました：エディター、検索ツール、コードプリプロセッサー。
完成したテキストフォーマット機能がINSTRUMENTEDされたとき、彼らは処理時間のほとんどがテキストの入出力を実行する3つのルーチンに費やされていることを発見しました（元の本では、io関数は89％の時間を要しました。パスカルブックでは、これらの関数は55％消費しました！）
彼らはこれらの3つのルーチンを最適化することができ、合理的で管理しやすい開発時間とコストでパフォーマンスの向上の結果を生み出しました。
読みやすさがなければ、本当に必要なときにパフォーマンスを向上させるのは非常に困難です。
パフォーマンスは、プログラムに問題がある場合にのみ改善する必要があります。この構文ではなく、ボトルネックになる場所がたくさんあります。<<で1nsの改善を求めているが、その10分のIO時間を無視したとします。
また、読みやすさに関しては、プロのプログラマーがコンピューターサイエンスの用語を読んだり理解したりできる必要があります。たとえば、putThisJobInWorkQueueと言う必要はなく、メソッドにenqueueという名前を付けることができます。
1時間のプロセッサ時間はどれくらいの費用がかかりますか？
1時間のプログラマーの時間はどれくらいの費用がかかりますか？
私見両方のことは何の関係もありません。最初に機能するコードを探す必要があります。これは、パフォーマンスや読み取りの程度よりも重要だからです。読みやすさについて：どのような場合でも、コードは常に読みやすくする必要があります。
ただし、コードが読み取れず、同時に優れたパフォーマンスを提供できない理由がわかりません。あなたの例では、2番目のバージョンは最初のバージョンと同じくらい読みやすいです。それについて読みにくいものは何ですか？プログラマーが左にシフトすることは2の累乗で乗算することと同じであり、右にシフトすることは2の累乗で除算することと同じであることを知らない場合...まあ、一般的な読みやすさよりもはるかに基本的な問題があります。