匠のコードベンチマーク：`Stopwatch` で暴く業務システムのボトルネックと高精度計測の極意
現場のエンジニアであれば、一度は直面したことがあるだろう。「この画面の処理がやたらと重い」「夜間バッチの終了時間が徐々に延び、始業時間に食い込み始めている」という悲鳴を。
そして、その原因を突き止めるために、古びたコードのあちこちに `DateTime.Now` を仕込み、`Debug.WriteLine` で差分を出力している姿を――。
断言しよう。`DateTime.Now` や `Environment.TickCount` を使ったパフォーマンス計測は、業務システムの最適化において「百害あって一利なし」の悪手である。
OSの時刻同期（NTP）やタイムゾーンの変更、さらにはタイマー解像度の限界に大きく依存するそれらの手法は、精度の低い物差しでミクロな外科手術を行うようなものだ。
今回は、VB.NETによるエンタープライズ開発の最前線において、CPUのハードウェアカウンター（高精度パフォーマンスカウンター）を直接叩き、ミリ秒・マイクロ秒単位でボトルネックを丸裸にする `System.Diagnostics.Stopwatch` クラスの極限活用術を伝授する。
—
1. なぜ `DateTime.Now` ではいけないのか？
初中級者が陥る最大の罠がこれだ。
.net
‘ 【アンチパターン】絶対にやってはいけない計測
Dim startTime As DateTime = DateTime.Now
‘ — 計測対象の処理 —
Dim endTime As DateTime = DateTime.Now
Dim elapsed As TimeSpan = endTime – startTime
Console.WriteLine($”処理時間: {elapsed.TotalMilliseconds} ms”)
このコードの何が問題か。
1. 分解能の限界: `DateTime.Now` の解像度はOSや環境に依存し、通常は10ミリ秒から15ミリ秒程度の誤差を含む。数ミリ秒で終わるループ内の処理を正確に測ることは不可能である。
2. システム時刻の干渉: 計測中にOSがNTPサーバーと時刻同期を行ったり、サマータイム等の影響を受けたりすると、経過時間がマイナスになることすらある。
これに対し、`Stopwatch` は内部で Win32 API の `QueryPerformanceCounter` （QPC）および `QueryPerformanceFrequency` をラップしており、CPUの非モダリティな高精度タイマーへ直接アクセスする。これにより、マイクロ秒（μs）オーダーの厳密な計測が可能となるのだ。
—
2. 実践：高精度ベンチマーククラスの設計
実務の現場では、単に `Stopwatch.StartNew()` を呼ぶだけでは不十分だ。ガベージコレクション（GC）のノイズや、JIT（Just-In-Time）コンパイルのオーバーヘッドを排除し、「純粋なアルゴリズムの実行コスト」を測定するための作法が存在する。
以下のコードは、シニアエンジニアが現場で即座に使える、高精度かつ安全な計測ラッパーの実装例である。
.net
Imports System.Diagnostics
Imports System.Runtime.CompilerServices
Namespace Enterprise.Diagnostics
”’
”’
Public NotInheritable Class ExecutionTimer
Implements IDisposable
Private ReadOnly _stopwatch As Stopwatch
Private ReadOnly _taskName As String
Private _disposed As Boolean = False
”’
”’
”’ ログ出力用の処理名
Public Sub New(taskName As String)
_taskName = taskName
‘ JITコンパイルの揺らぎを排除するため、事前にダミー実行を挟むことが望ましいが
‘ ここでは純粋なStopwatchの起動に特化する
_stopwatch = Stopwatch.StartNew()
End Sub
”’
”’
Public ReadOnly Property ElapsedMicroseconds As Double
Get
‘ Stopwatch.Frequency は 1秒あたりのチック数
Return CDbl(_stopwatch.ElapsedTicks) 1_000_000.0 / Stopwatch.Frequency
End Get
End Property
”’
”’
Public Sub Dispose() Implements IDisposable.Dispose
If _disposed Then Return
_stopwatch.Stop()
‘ 業務ログへ出力（本番環境ではNLogやSerilog等の構造化ログに渡すこと）
Dim elapsedMs As Double = _stopwatch.ElapsedMilliseconds
Dim elapsedUs As Double = ElapsedMicroseconds
System.Diagnostics.Debug.WriteLine($”[PERF] 処理完了 [{_taskName}] : 経過時間 {elapsedMs:F3} ms ({elapsedUs:F1} μs)”)
_disposed = True
End Sub
End Class
End Namespace
この設計のキモ
- `IDisposable` パターンの強制: `Using` 構文と組み合わせることで、例外発生時であっても確実にタイマーが停止され、リソースリークを防ぐ。
- マイクロ秒精度の算術: `.ElapsedMilliseconds` では丸められてしまう細かな差異を、`ElapsedTicks` と `Stopwatch.Frequency` から独自に計算して保持する。
—
3. レガシーなループ処理のボトルネックを暴く
では、実際の業務システムでよくある「非効率なループ処理」をこのタイマーで炙り出してみよう。
よくある悪例として、大量のマスターデータ（数万件）が存在するメモリ上コレクションに対し、LINQの `Where` や文字列結合をループの都度行っているケースを取り上げる。
.net
Imports Enterprise.Diagnostics
Public Class BatchAnalyzer
Public Sub RunAnalysis()
‘ ダミーデータの生成（10万件のレコードを想定）
Dim rawData = Enumerable.Range(1, 100000).Select(Function(i) New Record With {.Id = i, .Code = $”CODE_{i:D6}”, .Value = i 1.5}).ToList()
‘ 【ボトルネック計測の実行】
Using New ExecutionTimer(“非効率なループ処理（文字列結合と線形探索）”)
Dim targetCodes = {“CODE_050000”, “CODE_080000”, “CODE_099999”}
Dim results As New List(Of String)
For Each target In targetCodes
‘ 悪例：O(N)の検索をループ内で回す（線形探索）
Dim found = rawData.FirstOrDefault(Function(r) r.Code = target)
If found IsNot Nothing Then
‘ 悪例：非効率な文字列連結
Dim logStr = “ID: ” & found.Id.ToString() & ” / Value: ” & found.Value.ToString()
results.Add(logStr)
End If
Next
End Using
End Sub
End Class
Public Class Record
Public Property Id As Integer
Public Property Code As String
Public Property Value As Double
End Class
ボトリング結果の分析と改善
上記のコードを実測すると、10万件のコレクションに対する線形探索 (`FirstOrDefault`) と非効率な `String` 連結により、想像以上のミリ秒（場合によっては数十〜百ms以上）が消費されていることが判明する。
これをシニアエンジニアとしてどうリファクタリングするか。
1. O(N) から O(1) への換装: 事前に `Dictionary(Of String, Record)` へインデックス化しておく。
2. 文字列補間 / StringBuilder の活用: `&` による安易な文字列結合を排除する。
.net
‘ 【改善後】インデックス字典を用いた高速検索
Using New ExecutionTimer(“最適化されたループ処理（Dictionaryインデックス利用）”)
‘ 事前にO(1)で引けるDictionaryを構築（コンストラクタコストは別途考慮）
Dim indexedData = rawData.ToDictionary(Function(r) r.Code)
Dim targetCodes = {“CODE_050000”, “CODE_080000”, “CODE_099999″}
Dim results As New List(Of String)
For Each target In targetCodes
Dim found As Record = Nothing
If indexedData.TryGetValue(target, found) Then
‘ StringBuilder または 文字列補間 ($”…”) の使用
results.Add(String.Format(“ID: {0} / Value: {1}”, found.Id, found.Value))
End If
Next
End Using
計測結果を見れば一目瞭然である。改善後のコードは、計測誤差レベル（数マイクロ秒〜1ミリ秒未満）まで処理時間が圧縮される。「なんとなく遅い」を「何ミリ秒削減できた」という動かぬ証拠（エビデンス）に変えることこそが、プロフェッショナルなエンジニアの仕事である。
—
4. チーフアーキテクトからの警鐘：計測時の注意点
最後に、`Stopwatch` を扱う上で、現場のプロが絶対に知っておくべきハードウェアの裏側を共有しよう。
1. JITコンパイルのノイズ:
VB.NETアプリケーションの初回実行時は、IL（中間言語）からマシン語へのJITコンパイルが発生するため、最初の1回目の計測値は異常に跳ね上がる。ベンチマークを取る際は、「ウォームアップ実行（ダミー実行）」を必ず数回挟んでから本計測を行うこと。
2. CPUの省電力機能（Throttling）:
ノートPCや一部のサーバー環境では、CPUのクロック周波数が動的に変動する（Intel SpeedStepやAMD Cool’n’Quiet等）。これにより、測定のたびに実行時間がバラつくことがある。厳密な負荷テストやベンチマークは、電源プランを「高パフォーマンス」に固定した環境で行うのが鉄則だ。
3. マルチコア環境とスレッド親和性:
`Stopwatch` は高精度タイマーだが、スレッドが別のCPUコアにマイグレート（移動）した際、ごく稀にタイマーの不整合が生じるリスクが完全にゼロではない（近年のOSではハードウェア的に補正されているが）。極限のミリ秒を争う高頻度ポーリング処理などの計測では、`Thread.BeginThreadAffinity()` を用いてスレッドを特定コアに固定するテクニックも存在することを覚えておいて損はない。
—
結びにかえて
業務システムのパフォーマンスチューニングにおいて、勘や経験則でコードを書き換えるのはアマチュアのすることだ。
`Stopwatch` クラスという最強のメスを手にし、どこがボトルネックであり、リファクタリングによって何パーセントの改善効果があったのかを「数値」で語れ。
動くだけのコードは誰にでも書ける。しかし、限界まで最適化され、構造化された美しいコードベースを維持し続けることこそが、我々VB.NETエンジニアのプライドなのだから。
