どんな処理に時間がかかるのか

　今回からパフォーマンスチューニングについて取り上げたいと思います。プログラムはただ作ればそれで終わりというものではありません。より効率的に、高速に動作するように改良したいですよね。

　パフォーマンスを改良するのにも方法論があります。ただなんとなくやっても効果は出たり出なかったりということになるでしょう。

　まず、チューニングを始める前に、どこまでチューニングするのかという問題がありますね。本当は「このレベルまで改良する」という目標をたてます。例えば、「ユーザがボタンを押してから２秒以内に反応が返ってくる」みたいな数値的な目標です。

　これは工数との兼ね合いを考えた場合ですね。チューニングは際限なくやったらきりがないので、ある程度かかる工数と出せる効果のバランスをみて、ちょうどいいところで切り上げるというやりかたをします。

　でもこれは、仕事的なプログラミングの話です。このページはあくまで趣味的なプログラミングで考えていますので、言えることは、「気のすむまでやってください」です(笑)

　では、実際のチューニングに入りましょう。まず、プログラムの実行に時間がかかっているとしたら、何に時間がかかっているのかを冷静に分析します。ここで注目するのは「実行時間」です。プログラムの作りのまずさや、コードサイズなどはこの際無視して、実行時間が速いか遅いかだけに注目します。

　例えば、処理A→処理B→処理Cという順番で処理を実行していくプログラムがあるとします。このプログラムが遅い場合、それぞれの処理にかかる実行時間を測定します。

　処理A〜Cがほぼ同じ処理時間である場合は、さらに細かく分析していきます。Aの中のこの処理が遅い、Bの中のこの処理が遅いなんてことがいくつか分かってきたら、それらに関連性がないか、共通な処理はないかを追求していき、遅い部分を特定していきます。

　プログラムの様々な処理が、平均的に時間がかかっているなんてことはまずありません。ほとんどの場合は、処理A〜Cのなかで突出して時間のかかっている処理があります。

　この時間のかかっている処理が"パフォーマンスクリティカルな"処理になります。パフォーマンスチューニングでは、この部分を徹底的に改良していきます。他の部分はどんなに下手なつくりであっても、パフォーマンスには影響しないので、改良の対象にはしません。

　このように、改良の対象とする領域を明確にすることが最初の作業です。

　次回はパフォーマンスのネックになりがちな、「ファイル入出力」の効率化を取り上げたいと思います。