推測するな計測せよ

https://ja.wikipedia.org/wiki/UNIX%E5%93%B2%E5%AD%A6

UNIX哲学として知られている（直接にはUNIX哲学ではない、らしいです）格言です。

当社の某サービスには2000件程度（現時点では。どんどん増える見込み）のデータを取得している画面があるのですが、2秒ほどデータの取得に時間がかかっているためパフォーマンスチューニングを考えていました。

複雑な検索SQLが実行されているため、そこがボトルネックになっているだろうといろいろと調べてみたのですが、ふと「本当にここがボトルネックか？」と気になってプレゼン層からデータアクセス層までの各呼び出しで呼び出し時間を計測してみました。 その結果、実際にはSQLは0.5秒以内とそこそこ高速に実行されている事実がわかりました。

結局、本当に時間がかかっている箇所はアプリケーション層からプレゼン層に帰るときのドメインオブジェクトからDTOへの詰替えで、その処理の中でThread Safeにもかかわらずコストの掛かるインスタンス生成処理を繰り返していることが原因と突き止めました。

このように、パフォーマンスチューニングを行う場合は推測よりもまず本当にそこがボトルネックなのか計測をすることが肝心だな、と紹介した格言通りの経験をしたというポエムです。

なお、パフォーマンスチューニングをしようにもスパゲティだと難しくなります。 どこがボトルネックか探そうにもビジネスロジックが散在しているため、効果的に対策が可能な箇所が特定できないためです。

コーディング中、パフォーマンスの事を考えてアルゴリズムを工夫することがあるかと思いますが、 それよりもまずは可読性とメンテナンス性を重要視しましょう。 まず、ほとんどの場所ではパフォーマンスの問題はおきません。

そして問題が起きたとしても、可読性とメンテナンス性が高いコードであれば、パフォーマンスチューニングをすべき箇所はすぐに見つけられ、最適化も容易に行えるはずです。

以上、ポエムでした。