For developers building finance, banking, ERP, and other data-heavy systems, the data grid is often the primary performance boundary – the \u201chot loop\u201d where sorting and filtering across large datasets compete for main-thread time. In these cases, small inefficiencies quickly become user-visible and break interaction. <\/p>\n\n\n\n
But we found a solution. This post will demonstrate how we optimized sorting and filtering to keep Ignite UI fast at 1M+ rows across frameworks (Angular, React, Blazor, Web Components). We\u2019ll focus on the concrete data grid sorting and filtering changes that worked and the ones that didn\u2019t. <\/p>\n\n\n\n
Let\u2019s see what we did. <\/p>\n\n\n\n
Every performance problem starts the same way – an architecture that was reasonable at one scale becomes a bottleneck at another. Features like Ignite UI’s sorting, grouping, and filtering were no exception. <\/p>\n\n\n\n
The core sorting pipeline worked recursively, processing each sorting expression in sequence. For multi-column sorting, after sorting by the primary expression, it grouped equal-value records and recursively sorted each group by the next expression. Clean, correct, and completely reasonable for small datasets. <\/p>\n\n\n\n
The problem was the value resolver. <\/p>\n\n\n\n
Because the grid supports multiple column data types – date portions of Date objects, time portions of Date objects, strings, numbers, hierarchical key-value objects – every value comparison required resolving the field value at runtime. The value resolver handled path traversal, date parsing, and time normalization, number parsing, all on every single comparison. It was called twice per comparison operation – once for each side: <\/p>\n\n\n\n
compare(recordA, recordB): \n\n valA = resolveValue(recordA, field) \/\/ path traversal + date parsing + type coercion \n\n valB = resolveValue(recordB, field) \/\/ same cost, every single comparison \n\n return compareValues(valA, valB) <\/pre>\n\n\n\nFor a standard comparison sort, that’s