Datagrid: interruptable & incremental filtering

[romgrk]

This discussion summarizes the options for adding those two capabilities. Interruptable filtering allows to cancel a computation if the current filter is canceled by the user (e.g. by typing more characters), while incremental filtering allows to return partial results before the full computation is completed (e.g. to allow rendering the first N results as soon as possible, which makes the filtering feel basically instant, where N can be defined as the amound of visible rows).

Acquiring those capabilities means implementing either a concurrent solution (on the main thread) or a parallel solution (on a web worker thread). Both of them mean that our filtering interface becomes asynchronous.

Solutions

Concurency

A concurrent solution would be to split the filtering work in small batches and compute them one at a time, delaying the rest for a certain delay if the computation takes too long to run. This is the same technique used by React for rendering. The advantage is that there is no data copy. However, we don't get access to React scheduler (ignoring react.__secret_internals_do_not_use_or_you_will_be_fired which is obviously not meant to be public), so the filtering would be competing for the CPU with React.

Parallelism

A parallel solution would be to filter the data in a web worker thread. The advantage is that we can use more than one core and don't have any scheduling problems. The disadvantage is that we need to make a copy of the full dataset to allow filtering it.
A possible way to avoid having 2 full copies would be to treat web-worker threads the same way we treat server-side filtering, and the full data would live only in the web-worker thread. Implemented properly, this could give very good results.

Other notes

If we can also make our filtering more modular, we could also allow replacing parts of it easily, to allow for things like WASM-powered filtering.

Please leave your comments.

[lauri865]

What's the size of a dataset that measurably benefits from these optimisations?

I'm personally yet to come across a dataset where filtering gets noticably slow with our home built filtering system that we've integrated with MUI datagrid. So,I'm wondering if there are lower hanging fruits for you to optimise than parallelisation that would benefit most(?) of the users without incurring costs on complexity/maintainability, extensibilty and bundle size.

[romgrk]

Basically anything where the filtering computation runtime takes longer than a frame (16ms) can benefit from this. In particular, this would allow us to lower the on-type filter debounce delay to basically 0, because the computation would be cancelable.

with our home built filtering system that we've integrated with MUI datagrid

Would you care to expand on that? It'll help me understand better how you use the grid.

I'm wondering if there are lower hanging fruits for you to optimise than parallelisation that would benefit most(?) of the users

If we're talking about filtering performance specifically, we've gathered all those fruits recently in #9120 (that PR was split into multiple ones, most already merged).

[lauri865]

Instant filtering sounds nice in theory, but in practice, the experience could instead be distracting to the user to see things bouncing around on each keystroke (I often debounce input fields for this reason rather than for any performance gains). Or the bottleneck may also become too frequent updates to the DOM rather than calculating the filter state.

Would you care to expand on that? It'll help me understand better how you use the grid.

We have filters built around the datagrid, so we don't make use of the built-in filters. An important consideration for us was that we wanted to use our filtering system for a multitude of views, not just the datagrid, which disqualified using the internal filtering of the datagrid right off the bat, as it's not modular enough to reuse elsewhere.

What we have is essentially a combobox where you search for the column you want to filter by, and depending on the data type, you have auto-generated options from the data or natural language based filtering for dates and numbers, and you get instant feedback on the number of results each filter will show. Also, rather than filters being highlighted in individual columns, where they are difficult to grasp, they are rather listed on top of the datagrid where you can quickly add/edit/remove them. And URL-first state management for shareable links and easy persistence. It's inspired by what Linear.app has done, but extended to more data types.

[cherniavskii]

Thank you for putting this up! Interruptable filtering sounds interesting indeed 🙂

I wonder what improvements this can bring for the end users.
For client-side filtering, we could lower the filter input debounce or even remove it completely?
Frankly, client-side filtering already feels super fast on 100k rows dataset.
For server-side filtering, we will still keep debouncing to avoid sending tons of requests to the server.

[romgrk]

Yes, this is only useful for users who filter on the client-side.

Sometimes I find it hard to understand what our users are doing with the grid, and which proportion use it on the client/server side, and with which datasets. Do we have any data about that?