分岐の多用はアリかナシか

Question

プログラミングにおいて分岐命令の多用は避けた方がよろしいのでしょうか？
コードの読みやすさの話ではなく、処理速度の低下に繋がるかどうかが知りたいです。
パイプラインがどうとかハザードがどうとか、概念的には習ったのですが、実際の開発においてそこらへんは気にする必要はあるのでしょうか？調べてみても見やすさについての記述しか見つけられませんでした。。
又、デバイス(環境)によって異なるものでしょうか？僕が現在開発しているのはAndroidですが、もし異なるのであればその種類も教えて欲しいです。

Answer 1

分岐命令の多用は避けた方がよろしいのでしょうか？（中略）処理速度の低下に繋がるかどうかが知りたいです。

速度が気になった場合、鉄則としてはまず計測です。どのような環境でどう動かすかにもよりますので、実際の動作を見てみないと決定的なことはいえません。

ただ、（3DCGとか、インタプリタのメインループとかのような極端にCPU律速な処理を除いて）分岐命令のペナルティが主要な速度低下要因となることはそうそうないと思います。最適化の鉄則は「必要になってから行う」なので、普段は読みやすさ優先でコーディングすべきです（開発工数やバグを発生させるなどで、読みにくいコードは負担となるだけです）。

Comments

[mosuke]

ご回答ありがとうございます！
最適化の鉄則、とてもタメになりました。まずは読みやすさ優先でコーディングをしていこうと思います。

Answer 2

処理速度というのは短ければ短いほどいいのかというとそうではありません。
必要な要件をクリアしていればいいのです。それより拡張性やバグがない等の事の方が重要度が高くなる事はよくあります。（というか大半はそうです）

パレート(80:20)の法則というのがあります。プログラミングに限った話ではないのですが、
プログラミングの世界でもよく使われれます。

・プログラムの処理にかかる時間の80%はコード全体の20%の部分が占める
・プログラムの80%のバグは20%のモジュールで発生する

これは裏を返すと全体を満遍なく最適化しても、
それが意味をもつのは全体の２割しかなく残りの８割の作業は徒労に終わるのです。
maisumakun様の仰られる通り
最適化の鉄則は「必要になってから行う」

これが重要です。

追記：
私の知る限り、初期段階から処理速度の事を常に考慮しておかないといけない分野は下記のようなものです
・データベース
・コンバーター（画像の変換、圧縮ツール等）
・グラフィックス（ゲームの描画処理部分、動画関連のツール）
・ゲーム（AIの思考、衝突判定処理、物理演算、描画、逆にそれ以外は今のスペックだと特に気にしなくても問題になるケースはあまりない）

Comments

[mosuke]

パレートの法則について調べてみました。日本語難しいですね。
噛み砕いてご説明して頂いたお陰でとても分かりやすかったです！
現在DBの機能を実装しているので、ある程度処理速度に気を遣おうと思いますが、分岐命令の削減等の細かい部分は必要になったら考えようと思います。
ご回答ありがとうございました！