ベンチマークの落とし穴8選｜JMH・p99・ウォームアップ

「こっちの書き方が速いらしい」——その根拠、自分で測った数字ですか。

計測は簡単そうに見えて、素朴に測るとほぼ確実に間違えます。JITに消され、平均に騙され、ウォームアップを忘れる。今回は、その落とし穴を8つ集めました。1つでも知らなかったら儲けものです。

① 結果を使わない処理は、まるごと消されます

いちばん多い失敗です。

long start = System.nanoTime();
for (int i = 0; i < 1_000_000; i++) {
    expensiveCalc(i);   // 戻り値を捨てている
}
// → 「0ナノ秒」！？

コンパイラやJITは賢いので、「結果がどこにも使われていない処理は、実行しても無意味」と判断して丸ごと削除します。デッドコード除去です。

測ったつもりが、測る対象ごと消えていた。計測結果は、必ずどこかで使う（合計を出力するなど）。これを忘れると、幻の高速化を報告することになります。

② JVMは、走りながら速くなります

Javaで計測するとき、最初の数千回と、その後で速度が全然違います。

JVMは最初はインタプリタで動き、「よく通る場所」を検知してから機械語にコンパイル（JIT）します。さらに実行中の傾向を見て最適化を重ねる。

つまり起動直後の遅い状態（ウォームアップ前）で測ると、本来の速度の何倍も遅い数字が出ます。

だから正しい計測は、先に空回しして温めてから本番を測る。この「ウォームアップ」を知らないと、Javaのベンチは全部嘘になるんです。

③ 平均は、平気で嘘をつきます

「平均レスポンス60ms」——この数字だけで安心してはいけません。

100人中95人が10msで、5人が1000msでも、平均は約60msになります。平均は、少数の極端な遅さを薄めて隠すんですよね。

だから性能の世界では、平均ではなくパーセンタイルを見ます。p99（遅い方から1%を除いた値）は「ほぼ全員がこれ以内」の実感に近い。この例なら、p99は1000msです。

「平均は良いのに、たまに激遅というクレーム」の正体は、平均が隠したp99。見る数字を変えるだけで、問題が見えるんです。

④ 1回の計測は、計測ではありません

ストップウォッチ1回で「速い」と結論——危険です。

同じコードでも、実行ごとに数字は揺れます。他プロセスの割り込み、GC、CPUの周波数変動、OSのスケジューリング。ノイズだらけなんです。

だから計測は、何度も繰り返して分布で見る。1回だけの数字は、たまたま速かった・遅かったかもしれない、と疑うのが基本姿勢です。

「1回測って0.1秒差だから速い」は、ほぼ誤差の範囲。科学の実験と同じで、再現性が命なんです。

⑤ 開発環境の速さは、本番の速さではありません

手元のPCで測って速かった。本番も速いはず——とは限りません。

本番は、CPUの世代もメモリ量も、コンテナの資源制限も、同時に走る他プロセスの数も違います。データ量も桁違いのことが多い。

とくにデータ量は効きます。1000件では一瞬でも、1000万件では非線形に遅くなる処理は珍しくありません。

だから性能の確認は、本番に近い環境・本番に近いデータ量で。「手元で速い」は仮説であって、証明ではないんです。

⑥ マイクロベンチは、専用の道具で測ります

①②のような罠を、人間が全部避けるのは至難です。だから専用ツールがあります。

JavaならJMHが定番。戻り値を「消させない」仕組み（Blackhole）、自動ウォームアップ、複数回の統計処理——素朴な計測の落とし穴を、フレームワークが構造的に防いでくれます。

「自分でstartとendを引き算する」手書き計測は、学習にはよくても結論には使わない。計測にも、専用の道具を使うのがプロの流儀なんです。

⑦ 「速くする」前に、「どこが遅いか」を測ります

最速の最適化は、そもそも最適化しないこと——見当違いの場所を速くしないことです。

経験則として、実行時間の大半は、コードのごく一部（ホットスポット）に集中します。全体を勘で磨くのは、時間の99%を1%の高速化に費やす行為になりかねません。

だから順番は、まずプロファイラで「時間がどこに消えているか」を測り、上位だけを直す。

「推測するな、計測せよ」——性能改善で最も有名な格言が、ここに効くんです。

⑧ 速いコードより、消したコードが最強です

究極の高速化を、最後に。どんなに速く書いても、そもそも実行しないコードには勝てません。

• 同じ計算を毎回やっている → 結果をキャッシュ
• ループの中で毎回DBに問い合わせ → まとめて1回に
• 呼ぶ必要のない処理を呼んでいる → 呼ばない

アルゴリズムやI/Oの見直しは、コードの書き方チューニングより桁違いに効きます。for文を1行速くする前に、「このループ、そもそも要る？」を問う。

最も速い処理は、実行されない処理。計測が教えてくれるのは、たいていこの事実なんです。

番外編：知っておくと得する小ネタ

「体感」も立派なデータです
数字が同じでも、待たされ方で体感は変わります。処理中にスピナーを出す、先に一部を表示する——知覚される速度の改善は、実測を変えずに満足度を上げる別軸です。

時刻取得のコストにも注意
計測のために時刻を取る処理自体に、わずかなコストがあります。極小の処理を測るときは、計測コードが結果を汚していないかも疑うんです。

「速い言語」より「速い書き方」
言語間の速度差より、同じ言語内のアルゴリズムの差の方が大きいことがほとんどです。⑧のとおり、まず自分のコードを疑うのが先です。

RJCでも、計測と向き合っています

RJCが携わるシステムでは、「速くなった気がする」では通用しない場面があります。⑦の「まず計測」は、性能改善の提案を数字で語るための土台なんですよね。

こういう姿勢を、Techチームで共有しながら開発しています。

よくいただくご質問

Q. まずどれから押さえるべきですか？
A. ⑦かなと思います。「速くする前に、どこが遅いかを測る」——この順番を守るだけで、努力が無駄になりにくいんですよね。

Q. 簡単な速度比較でも、ツールが必要ですか？
A. 結論を人に伝えるなら、必要です。①②の罠は手書き計測では避けきれないので、JMHのような道具の数字の方が信頼されるんです。

Q. p99って、どう使えばいいですか？
A. 「ほぼ全ユーザーがこの速度以内」の指標として、平均と一緒に見るのがおすすめです。③のとおり、クレームの正体はたいてい平均の外にいます。

Q. 未経験からでも、分かるようになりますか？
A. なります。計測は「思い込みを数字で確かめる」だけなので、むしろ先入観が少ない人ほど素直に測れるんです。

「速いらしい」を、「速い」に変える

今日の8つに共通していたのは、これでした。

性能の話は、伝聞と体感と思い込みが混ざりやすい分野です。JITに消され、平均に隠され、環境で化ける。

だからこそ、正しく測れる人の一言が強い。「速いらしい」ではなく「測ったらこうだった」と言える人が、チューニングの議論を前に進めるんですよね。

みなさんが引っかかった計測の罠、よかったら教えてください。