DataGridViewの「重い」を終わらせる：VirtualModeによる100万件表示の極意
業務アプリケーションにおいて、数万件のデータを`DataGridView`に放り込んでフリーズさせた経験はないだろうか？
「データを全部読み込んでバインドする」というやり方は、小規模なマスタ管理なら通用する。だが、10万件を超えた瞬間にメモリは飽和し、UIスレッドは固まり、ユーザーは「このアプリ、使えない」と判断する。
結論から言おう。DataGridViewに全件持たせてはいけない。
表示に必要な分だけを、動的に供給する「仮想モード(VirtualMode)」こそが、プロフェッショナルの解だ。今回は、メモリ消費を極限まで抑えつつ、サクサク動くUIを構築する設計論を叩き込む。
—
1. なぜ「データバインド」は死ぬのか
通常、`DataSource`に`DataTable`や`List(Of T)`を突っ込むと、DataGridViewは内部ですべての行オブジェクトを生成し、スタイルやプロパティを保持しようとする。
- メモリ肥大化: 1行あたり数KB消費するオブジェクトが数万個生成される。
- 描画遅延: スクロールするたびに、DataGridViewが全ての行の計算を行おうとする。
- GCの悲鳴: 大量のメモリ確保・解放により、ガベージコレクションが頻発し、アプリが断続的に停止する。
これを解決するのが `VirtualMode = True` だ。これは「データは俺（アプリ側）が持っている。お前（DataGridView）は表示する時だけ俺に聞きに来い」という契約を結ぶことを意味する。
—
2. 仮想モードを掌握するアーキテクチャ
必要なのは、「データソース（ListやDB）」と「DataGridView」の間に、必要最小限のビューを提供するキャッシュ機構を持つことだ。
実装のキモ：CellValueNeededイベント
`CellValueNeeded`は、画面に表示されるセルが必要になるたびに発火する。ここで、「今、何行目の、どの列を求めているか」を判断し、データソースから値を返却する。
—
3. 実践コード：保守性の高い実装例
以下のコードは、数百万件のデータでもメモリ消費を一定に保つための設計だ。
Imports System.Collections.Generic
Public Class DataManager
‘ 巨大なデータソースのシミュレーション
Private _dataStore As List(Of MyRecord) = New List(Of MyRecord)()
Public Sub New()
‘ 100万件のダミーデータ生成
For i As Integer = 0 To 1000000
_dataStore.Add(New MyRecord With {.Id = i, .Value = “Data ” & i})
Next
End Sub
‘ インデクサを公開してアクセスを制御
Public ReadOnly Property Records As List(Of MyRecord)
Get
Return _dataStore
End Get
End Property
End Class
‘ フォーム側での実装
Public Class MainForm
Private _manager As New DataManager()
Private Sub MainForm_Load(sender As Object, e As EventArgs) Handles MyBase.Load
‘ 1. 仮想モードをONにする
dgvMain.VirtualMode = True
dgvMain.RowCount = _manager.Records.Count
End Sub
‘ 2. セル描画時に呼ばれるイベント（ここが心臓部）
Private Sub dgvMain_CellValueNeeded(sender As Object, e As DataGridViewCellValueEventArgs) Handles dgvMain.CellValueNeeded
‘ 行番号が範囲内かチェック（例外を防ぐ堅牢なコード）
If e.RowIndex < 0 OrElse e.RowIndex >= _manager.Records.Count Then Return
Dim record = _manager.Records(e.RowIndex)
‘ 列名に応じて値を返す
Select Case dgvMain.Columns(e.ColumnIndex).Name
Case “colId”
e.Value = record.Id
Case “colValue”
e.Value = record.Value
End Select
End Sub
End Class
—
4. プロダクション環境への注意点
この設計を実務に落とし込む際、以下の3点を必ず守れ。
1. データソースの型を意識せよ:
数百万件をメモリに乗せるのが不可能な場合、`List(Of T)`ではなく、`SQLite`や`SQL Server`から必要なページ分（例：0〜100件）だけを`SELECT`する「ページング処理」と組み合わせるのが正解だ。
2. CellValueNeededは「超」軽量に:
このイベントは秒間に何度も呼ばれる。この中で重い計算や、ファイル・DBへのIOアクセスを書いてはいけない。データは必ずメモリ内（またはキャッシュ）から取得するように設計せよ。
3. スタイルの適用も注意:
`CellFormatting`イベントも同様に頻発する。条件付き書式（背景色を変える等）が必要な場合、ロジックを極限までシンプルに保て。複雑な判定を入れるとスクロールがカクつく。
—
最後に：エンジニアとしての矜持
「とりあえず動く」コードを書くのは誰でもできる。しかし、数万件のデータを扱った瞬間に破綻する設計は、プロとしては失格だ。
`VirtualMode`を導入するということは、「フレームワークが裏で何をやっているか」を理解し、その挙動を制御下におくという意志表示に他ならない。このアプローチを習得すれば、君の作るツールは、どんな巨大なデータセットを渡されても涼しい顔で動作するはずだ。
次は、このアーキテクチャに「検索フィルタ」や「非同期データ読み込み」をどう組み込むか……。それはまた別の機会に話そう。まずは、目の前のDataGridViewを爆速化させることから始めてほしい。
