logo header
logo header
logo header
logo header
  • 2016.05.16
  • 技術ブログ開発

コード最適化が最適ではない3つのケース

code

こんにちは、農道JSです。
今回はコード最適化について話をしたいと思います。

必要でない最適化がされるケースもある

コードの最適化を行えば、処理が早くなります。本来いいことなはずですね。
それが必要とされるケースで、必要とされる程度の最適化ができると、いいことですよね。
ただ、このソフトウェア開発業界では、そうじゃないケースは割と多いと思います。
という事で、個人的によく見たことがある3つのケースを紹介したいと思います。

1: 最適化を行わなくても良い時に最適化を行う

いわゆる「早まった最適化」です。
ドナルド・クヌースさんの言葉を借りると:

早まった最適化は諸悪の根源である
("Premature optimization is the root of all evil in programming")

最適化は必要かどうかはまだ分からないのに、時間(と可読性など)を犠牲にして最適化を行うのはいい事ではありません。
最低限のパフォーマンス目標があるはずです。
最適化なしでそれを果たせるのであれば、何も犠牲にしなくてもいいです。

2: 最適化の為、可読性を犠牲にする

可読性が開発の時間に影響がありますので、すごく重要です。
最適化を行うべきケースもあります。
確かに、最適化も可読性も必ず100%理想通りになれるかどうかというと、そうじゃないケースは間違いなくあります。
と言っても、最適化と可読性は相互排他的な関係ではありません。
最適化されたコードをその最適化に影響がない形で読みやすくできないケースは少ないと思います。

3: 思い込みベースで最適化を行う

この書き方・やり方だと、最適化ができる

  • と思います
  • と聞いた事があります
  • と言われた事があります
  • の気がします

が、測ってないです。
根拠のないベースで、最適化を行うと、時間が無駄になることをしているかもしれないし、意味がない程度の最適化をやっているかもしれません。最悪のケースだと、何かを悪くしてしまうかもしれないです。

じゃ、どうすべき?

最適化を行う時はパフォーマンス目標達成できなかった時です。
目標と現状の比較によって、その差を測ります。
そのあと、ボトルネックがどこにあるを測ります。
それをベースにし、コード最適化を行って、測り直します。
パフォーマンス目標を達成できた後、コードは読みにくいのであれば、最適化に影響がない形で読みやすくします。

最後に

最後に、またドナルド・クヌースさんの言葉を借りたいと思います:

細かい効率のことは忘れて、時間の97%について考えよう。時期尚早な最適化は諸悪の根源だ。それでも残り3%についても機会を逃すべきではない
("We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%")

ともに世界をアップグレードできる、そんな日を夢見て。
Upgrade the World!