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

Transcript

1. 開発運用研修2025 パフォーマンス・チューニング （公開用） サイボウズ・ラボ 川合 秀実 1
2. パフォーマンス・チューニングとは？ • [重要]プログラムの実行速度を速めたり、メモリ消費量を抑え たりする、プログラミングの技術です。 • これがうまいと周囲の人から尊敬されます。 • [Q]じゃあみんなぜひ習得するべきですね！ みんなでスター級のプログラマになりましょう！ • [A]いいえ、実はそうではないのです。だからほとんどの人は 前半だけ読んで、「おしまい」でいいです。 2
3. 川合の自己紹介 • この資料を書いた人は、どんな人ですか？信用できますか？ • 「30日でできる！OS自作入門」という本を書いた人です（2006年） • （信用できるかどうかはわかりません） • 2011年9月から、サイボウズ・ラボに所属しています 3
4. パフォーマンス・チューニングの実例#1 4 （社外秘情報を含むのでこのページは削除されました）
5. パフォーマンス・チューニングの実例#2 5 （社外秘情報を含むのでこのページは削除されました）
6. どうしてそんなに速くなるの？#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
7. どうしてそんなに速くなるの？#2 7 （社外秘情報を含むのでこのページは削除されました）
8. パフォーマンス・チューニングのデメリット#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
9. パフォーマンス・チューニングのデメリット#2 • チューニングはたいてい、プログラムの読みやすさを低下させ ます。 • 読みにくくなって、バグを見つけにくくなるほうが有害です。 • それでお客様のデータを失ってしまったら大事件です！ • だから「必要になるまで」チューニングなんてしないほうが いいです。普段はわかりやすくて確実な書き方をしましょう。 • たまにチューニングしていたら無駄な処理を見つけて、それを省いた らかえってプログラムが読みやすくなることがあります。それはこの デメリットには当たらないので、遠慮しないでやってください。 9
10. パフォーマンス・チューニングのデメリット#3 • すごく頑張ってチューニングしたのに、数年たつと「工夫しないで 素直に書いたほうが速くなる」ことがあります。 • これはMySQLやコンパイラの能力が上がり、普通の書き方でも自動 で最適化ができるようになり、そのほうが性能が出る場合がある ためです（技術の進歩です）。 • だからチューニング前の状態に簡単に戻せるようにしておくべき です。そして時々、チューニングしない場合で性能がどうなのか 確認するべきです。 • チューニング部分はよくバグるので、バグの切り分けの際には、 まずチューニングなしの状態でも再現するかを確認しましょう。 そうすれば、チューニングした人のせいかどうかすぐわかります。 10
11. がんばれば、どこまででも速くなる？ • そのように誤解する人がたまにいますが、そんなことはないで す。 • 限界はすぐに来ます。 • パフォーマンスチューニングで可能なのは無駄な処理時間を 削っていくことであって、それ以外の処理時間は全く減らせま せん。無駄のないプログラムになってしまったら、もう1秒た りとも高速化できません。 11
12. チューニングの80:20の法則 • プログラムの処理時間のうちの80%は、コード全体の20%の部分が 占める。 • 例えばループの中は3行しか書いてなくても何度も実行される。ルー プの外とかは1000行書いても1回しか実行されない。高頻度で繰り 返される部分は、ソースコード全体の20%程度であるという法則。 • だからコードの80%の部分は高速化してもほぼ効果がない。 • 効き目のある部分を見極めて、そこだけチューニングするべき。 • ちなみに80:20っていうのは雑な値で、実際は95:5とかだったりする ので、ここぞというところを直すだけで、劇的に速くなることが あります。 12
13. チューニングする前に処理時間測定だ！ • 時間がかかっているところがどこなのかを知るために、「この処理 からこの処理までにかかった時間は〇秒」みたいなのを、ていねい に測ります。 • このループが遅い、この関数が遅い、みたいなのがわかったら、そ こをじっと見ます。 • 見ているうちに速くできそうな方法を思いついたら、試してみます。 • 普通の人は思いつかないので、思いつかなくてもがっかりしないでください。 • 速くなっている「はず」はダメ。ちゃんと効果を測定すること。 • 実際に採用するかどうかは、「読みにくさ」と「高速性」のバラン スを意識します。 13
14. そのあとに推奨される行動 • 十分に高速化できないのであれば、パフォーマンスチューニン グが得意な人に相談します（ラボの川合でも可）。 • もちろんこれを機に自分がパフォーマンスチューニングに挑戦 してみてもいいです。 • やってみて面白かったらパフォーマンス屋さんになってもいい です。 14
15. ここから上級編（ほとんどの人は読む必要なし） • もしあなたがパフォーマンス・チューニング担当になったら？ • まず具体的に何を高速化するか正確に決める（どのデータでや るかとか）。 • そして時間を測り、どこで時間がかかっているのかを見極める。 • これは基本どおり • チューニングのためにどのくらいの工数をかけていいのかを確 認する（これは意外に重要）。 15
16. 私のやりかた • もし私が「高速化の余地はもう残っていませんでした」と報告 すれば、みんなはそれを信じるから、責任重大。 • そもそも簡単にできるような高速化はすべてやられたあとで、 私に回ってきているはず。 • だから普通なら見過ごされるような大技が期待されている。 • とにかく思いついたことを、片っ端から試してみるしかない。 • ただし工数を意識して、試すのに時間がかかりすぎるやつはや らない。 16
17. どうしようもないときは・・・ • 「そもそも、ここでこの値を正確に出さなきゃいけないんです かね？」 • たとえばGoogleで「サイボウズ」を検索すると • 約2,700,000件（0.23秒） • と出てきます。こういう雑な近似計算ではだめですか？ • などと、処理内容そのものを変更できないかと聞いてみたりす る。これがOKなら3倍は速くなるんですが・・・とか。 17
18. 私の仕事 • 私の仕事は提案すること。 • ここをこうしたら、これくらい速くなりますよ、どうですか？ • できるだけ少ない変更で、できるだけ大きな効果が出るように 提案する。 • たくさん書き換えて、すごく速くなるのはまあ当たり前。 • そんなこといわれても開発チームが採用できるわけない。 • もしこれでご不満なら、まだ試してみたいことはあるので、あ と1か月くらいは延長して研究できます。どうしますか？とか。 18
19. テクニック（詳細は省略） • 小技 • 場合分けをして、状況に応じて計算量を減らす • 割り算や剰余算は、足し算・引き算・掛け算よりも重い • 条件分岐を減らすと速くなることがある • 文字列処理は重い、数値処理で代用できるならそうする • 同じ計算は繰り返さないように結果を変数に入れる • 中技 • 近似計算などに切り替える • オブジェクトのnew/deleteも量が多いとまあまあ遅い • メモリ内のデータ構造を見直すことで、キャッシュヒット率が改善して速くなることがある （配列の添え字の入れ替えなども検討） • 一度計算した値は覚えておいて、再び同じ計算が出たら結果を探し出して計算の代わりにする （メモ化・計算結果キャッシュ） • 別のアルゴリズムにする • パフォーマンスチューニングの本を読む • 大技 • 「そういう使い方は推奨しない」みたいな「いいわけストーリー」を考える • 「押してもだめなら引いてみな」的な発想の逆転を試みる • 効率的な実行を軸に、全体的な設計を見直す（川合にとっては禁じ手） • 気分転換する、散歩する、旅に出る、瞑想する、ふて寝する、などなど・・・ 19