DataGridViewの呪縛を解く：VirtualModeによる数百万件描画の極致
VB.NETを扱うエンジニア諸君。業務システムで「DataGridViewに数万件のデータをバインドしたらアプリが固まる」という、初心者が必ず通る地獄を見たことはあるか？
標準的な`DataSource`へのデータテーブル直投げは、行数が5桁に達した瞬間に死を意味する。`.NET`のラッパーが各行の`DataGridViewRow`オブジェクトをメモリ上に生成し、各セルに対して個別にスタイル計算とレンダリングを行う。この「無駄の極み」がメモリを食いつぶし、ガベージコレクション（GC）を頻発させ、UIスレッドを停止させるのだ。
真のアーキテクトは、UIを「データの鏡」としてのみ扱う。今日は、`VirtualMode`を極めることで、数百万件のデータすら軽快に捌くための「深淵のテクニック」を伝授する。
—
1. VirtualModeの真髄：メモリを制する者
`VirtualMode = True` に設定した瞬間、`DataGridView`は自律的なデータ管理を放棄する。UIは「今、画面に表示すべき範囲」だけをあなたに要求してくる。あなたは、バックエンドのリストから「必要な行番号のデータ」を取り出し、UIに渡すだけの「プロキシ」に徹すればいい。
これにより、メモリ占有量は「表示行数分のみ」に固定される。数万件のレコードがあろうが、メモリ負荷は定数となるのだ。
2. 実装の極意：CellValueNeeded イベントの最適化
`CellValueNeeded` は、描画のたびに呼び出される。ここで重いDBクエリや複雑な型変換を行えば、即座に画面はカクつく。データは必ずメモリ内（`List(Of T)`等）にキャッシュした状態で、インデックスアクセスのみで完結させること。
‘ DataGridViewの仮想モード実装例
Private _dataCache As List(Of MyRecord) ‘ 数十万件のレコードを保持
Private Sub dgv_CellValueNeeded(sender As Object, e As DataGridViewCellValueEventArgs) Handles dgv.CellValueNeeded
‘ 範囲外アクセスをガード
If e.RowIndex < 0 OrElse e.RowIndex >= _dataCache.Count Then Return
‘ インデックスによる高速アクセス（O(1)）
Dim record = _dataCache(e.RowIndex)
Select Case dgv.Columns(e.ColumnIndex).Name
Case “ColID”
e.Value = record.ID
Case “ColName”
e.Value = record.Name
‘ ここで複雑な計算やフォーマットを行わないのが鉄則
End Select
End Sub
3. レガシー環境でのメモリ枯渇を防ぐ「明示的解放」
VB.NETのガベージコレクタは優秀だが、大量のデータを扱う際、特に`IDisposable`を実装したオブジェクトが混入すると、GCの追いつかないメモリリークが発生する。
- 大規模データは構造体(Structure)かプリミティブで保持する
- 不必要なイベントハンドラは必ず `RemoveHandler` で破棄する
- 画面遷移時は `DataSource` を `Nothing` にし、`GC.Collect()` を呼び出す（最終手段）
特に、`DataGridView`の `RowPostPaint` 等でWindows API（`User32.dll`）を呼び出し、GDIオブジェクトを直接描画している場合は、`Graphics.Dispose()` を忘れた瞬間にアプリは死に至る。
4. UIスレッドを解放する：非同期データ取得の設計
大量データをバックグラウンドでロードし、UIに反映する際は `BindingSource` を介さず、直接 `DataGridView.RowCount` を更新せよ。
‘ 非同期でデータを取り込み、UIを更新する流儀
Private Async Sub LoadDataAsync()
‘ 別スレッドで大量データを読み込み
Dim data = Await Task.Run(Function() FetchDataFromDatabase())
_dataCache = data
dgv.RowCount = _dataCache.Count ‘ 行数を設定するだけで、UIはCellValueNeededを呼び出す
dgv.Invalidate() ‘ 再描画を強制
End Sub
—
伝説のアーキテクトからの忠告
諸君、UIの遅延は多くの場合「データバインディングの過剰な機能」に起因している。`DataGridView`は本来、非常に強力なツールだが、それは「使い方を熟知したプロ」が扱った場合に限る。
もし、数百万件のデータをソートやフィルタリングしたいのであれば、`DataGridView`の機能をそのまま使おうとせず、「表示用データセット」をSQL側で `OFFSET / FETCH` を使ってページングするのが、システム設計としての正解だ。
「全てをメモリに載せる」のはアマチュアのすることだ。プロは「必要分だけを、必要な瞬間に、最速のパスで描画する」。このアーキテクチャこそが、レガシーとモダンを繋ぐVB.NETエンジニアが持つべき「魂」である。
次回の記事では、`User32.dll` を用いたグリッド描画のオーバーライドと、メモリマップドファイルによる大規模ログ表示の最適化について掘り下げる予定だ。準備しておけ。
