Upgrade to Pro — share decks privately, control downloads, hide ads and more …

パフォーマンス・チューニング【サイボウズ新人研修2025】

Avatar for Cybozu Cybozu
July 06, 2025
1.1k

 パフォーマンス・チューニング【サイボウズ新人研修2025】

Avatar for Cybozu

Cybozu

July 06, 2025
Tweet

More Decks by Cybozu

Transcript

  1. どうしてそんなに速くなるの?#1 • これだと、a=10001,b=20000で、掛け算1万回、足し算1万回 になります。 • 二乗和の公式を使えば・・・いずれも数回ですんでしまいます。 • sum = (b

    * (b + 1) * (2 * b + 1) – (a – 1) * a * (2 * a – 1)) / 6; • [1からbまでの和] ー [1から(a-1)までの和] • こういう感じで計算量を減らすのです。 sum = 0; for (k = a; k <= b; k++) sum += k * k; 6
  2. パフォーマンス・チューニングのデメリット#1 • 先ほどの例で、 • これは見るだけで、二乗の和を計算しているとすぐにわかります。 • しかし、 • sum =

    (b * (b + 1) * (2 * b + 1) – (a – 1) * a * (2 * a – 1)) / 6; • は、コメントがないと何をやっているかわかりません。 • もし書き間違えた場合、すぐに気づけるのはどちらでしょう? • コメントがあっても、ここは違うかも?って思って検算しなければ、 まあそんなものかーって流してしまい見逃しやすいでしょう。 sum = 0; for (k = a; k <= b; k++) sum += k * k; 8
  3. パフォーマンス・チューニングのデメリット#2 • チューニングはたいてい、プログラムの読みやすさを低下させ ます。 • 読みにくくなって、バグを見つけにくくなるほうが有害です。 • それでお客様のデータを失ってしまったら大事件です! • だから「必要になるまで」チューニングなんてしないほうが

    いいです。普段はわかりやすくて確実な書き方をしましょう。 • たまにチューニングしていたら無駄な処理を見つけて、それを省いた らかえってプログラムが読みやすくなることがあります。それはこの デメリットには当たらないので、遠慮しないでやってください。 9
  4. パフォーマンス・チューニングのデメリット#3 • すごく頑張ってチューニングしたのに、数年たつと「工夫しないで 素直に書いたほうが速くなる」ことがあります。 • これはMySQLやコンパイラの能力が上がり、普通の書き方でも自動 で最適化ができるようになり、そのほうが性能が出る場合がある ためです(技術の進歩です)。 • だからチューニング前の状態に簡単に戻せるようにしておくべき

    です。そして時々、チューニングしない場合で性能がどうなのか 確認するべきです。 • チューニング部分はよくバグるので、バグの切り分けの際には、 まずチューニングなしの状態でも再現するかを確認しましょう。 そうすれば、チューニングした人のせいかどうかすぐわかります。 10
  5. チューニングする前に処理時間測定だ! • 時間がかかっているところがどこなのかを知るために、「この処理 からこの処理までにかかった時間は〇秒」みたいなのを、ていねい に測ります。 • このループが遅い、この関数が遅い、みたいなのがわかったら、そ こをじっと見ます。 • 見ているうちに速くできそうな方法を思いついたら、試してみます。

    • 普通の人は思いつかないので、思いつかなくてもがっかりしないでください。 • 速くなっている「はず」はダメ。ちゃんと効果を測定すること。 • 実際に採用するかどうかは、「読みにくさ」と「高速性」のバラン スを意識します。 13
  6. 私の仕事 • 私の仕事は提案すること。 • ここをこうしたら、これくらい速くなりますよ、どうですか? • できるだけ少ない変更で、できるだけ大きな効果が出るように 提案する。 • たくさん書き換えて、すごく速くなるのはまあ当たり前。

    • そんなこといわれても開発チームが採用できるわけない。 • もしこれでご不満なら、まだ試してみたいことはあるので、あ と1か月くらいは延長して研究できます。どうしますか?とか。 18
  7. テクニック(詳細は省略) • 小技 • 場合分けをして、状況に応じて計算量を減らす • 割り算や剰余算は、足し算・引き算・掛け算よりも重い • 条件分岐を減らすと速くなることがある •

    文字列処理は重い、数値処理で代用できるならそうする • 同じ計算は繰り返さないように結果を変数に入れる • 中技 • 近似計算などに切り替える • オブジェクトのnew/deleteも量が多いとまあまあ遅い • メモリ内のデータ構造を見直すことで、キャッシュヒット率が改善して速くなることがある (配列の添え字の入れ替えなども検討) • 一度計算した値は覚えておいて、再び同じ計算が出たら結果を探し出して計算の代わりにする (メモ化・計算結果キャッシュ) • 別のアルゴリズムにする • パフォーマンスチューニングの本を読む • 大技 • 「そういう使い方は推奨しない」みたいな「いいわけストーリー」を考える • 「押してもだめなら引いてみな」的な発想の逆転を試みる • 効率的な実行を軸に、全体的な設計を見直す(川合にとっては禁じ手) • 気分転換する、散歩する、旅に出る、瞑想する、ふて寝する、などなど・・・ 19