You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
perf(grid): lazy overlay list in DataGridStagingBuffer to eliminate 50,000-row allocations on cell edits #1538
In DataGridStagingBuffer.effectiveRows (lib/features/workspace/data_grid_staging_buffer.dart), whenever a user edits a single cell or inserts a row, _buildRows is invoked.
This creates a full copy of the entire table (result = <List<String>>[]) copying 50,000 pointers, wrapped in List.unmodifiable.
During fast keyboard typing in an editable grid cell, this continuously allocates 50,000-element lists in the heap, causing garbage collection spikes.
Solution
Implement a lazy overlay row list (_LazyOverlayRowList implementing ListBase<List<String>>).
Return _originalRows[index] for unedited rows and the modified row overlay for edited rows directly in (1)$.
Eliminate the allocation of the full row list on every cell keystroke.
Benefits
0 full list allocations when editing grid cells.
Instant, zero-latency cell mutations regardless of table size (10k-100k rows).
effectiveRows is already cached (_cachedEffectiveRows) and only invalidated on a staged change; with no changes it returns _originalRows without allocating.
Edits are staged when a cell edit is committed (grid_cell_editing), not per keystroke.
Bench: rebuilding the effective list for 50k rows x 20 cols after one edit costs ~1.6 ms. That is below one frame at 120 Hz and happens once per committed edit.
A lazy ListBase overlay would add risk (index semantics for deleted/inserted rows, memoization in ResultsTab) for a gain nobody can notice.
Activity
ZhuchkaTriplesix commentedon Oct 12, 2026
Closing after measuring.
effectiveRowsis already cached (_cachedEffectiveRows) and only invalidated on a staged change; with no changes it returns_originalRowswithout allocating.grid_cell_editing), not per keystroke.A lazy
ListBaseoverlay would add risk (index semantics for deleted/inserted rows, memoization inResultsTab) for a gain nobody can notice.