.NETにおけるスレッドプールの効果

More Effective C#を読んでいたら、「項目11 スレッドを作らずにスレッドプールを使え」の中に、自前でスレッドを生成する処理と、スレッドプールを使う処理との処理時間の比較が載っていた。一般論として、自分でスレッドをわざわざ作るよりもフレームワーク側で用意されているスレッドプールを使う方が、スレッド生成に伴う時間が節約できて効率的だ。

しかし、同書の64ページに載っている比較グラフを見ると、その差があまりに大き過ぎるように感じられる。確かにスレッドプールを使う場合のパフォーマンスは素晴らしいのだけど、自分でスレッドを作る場合に時間がかかりすぎているようにも見える。スレッド生成の有無の違いだけで、本当にこれだけの性能差が生まれるものなのだろうか？気になったので、実際にC#のソースコードを動かして検証してみた。動作環境は下記の通り。ソースは書籍を参照。

• Windows XP/SP3
• Core2 Duo 2GHz
• .NET Framework 3.5

結果は下記のグラフの通り（横軸はスレッド数、縦軸は所要時間：msec）。結論を言うと、本に載っているグラフとほぼ同じ傾向だった。

• 単一スレッドの場合、常に同じ処理時間（当然）
• スレッドプールを使う場合、スレッド数に応じて処理時間はリニアに増える（スレッド切り替えのコスト）
• 自分でスレッドを作る場合、スレッドプールを使う場合と同様に処理時間はリニアに増えるが、スレッドプールの場合よりも処理時間がかかる（スレッド切り替え・生成のコスト）

スレッド生成の所要時間はもう少し小さいものだと思い込んでいたので、これほど時間がかかるものとは少々意外な結果だった。処理内容（今回はヘロンの公式を使って平方根を求めるもの）や動作環境（CPUのコア数等）にも依存するとは思うけど、マルチスレッドのソフトを作る際には、こんな違いが生じることは覚えておいた方が良さそうだ。

More Effective C#