perf(DataTable): speed up select-all with large tables

[mrspeaker]

Rewrite setAllSelectedState to improve performance with large tables. In my test case on my machine with 10000 rows, selecting all rows previously took 14000ms, this fix reduces it to 8ms. It uses one instance of (local) variable mutation.

Closes #6146
Closes #4338

The setAllSelectedState function is called when you click the select-all (or deselect all), or select one row then hit the cancel button on the bulk-action toolbar (in handleOnCancel). It appears to be "accidentally quadratic" and starts to become an issue with more than a few thousand rows. To avoid it, I do a local mutation of the accumulator rather than re-splatting out the entire object each iteration.

For 10000 rows, this reduces the original 14 second time (this is for Vite transpiled code, 8 seconds for native), down to ~250ms. Most of that time is in the filteredRowIds.includes check. So I added an extra flag (isFiltered) to avoid calling when the filter is not in use. When there are no filtered rows, the function runs in ~8ms.

Changelog

Testing / Reviewing

The fix does not break any existing tests, and should not introduce any changes to the existing behavior of the DataTable: Selecting-all/deselecting all should work as expected. When using the bulk-action toolbar, clicking cancel should deselect the row. If rows are filtered, clicking select-all should select all filtered rows.

To test the performance, you need to make a table with a lot of (at least 10000) rows. With a large dataset like this, the performance improvements are obvious, but if you want to measure it then wrap calls to setAllSelectedState with console.time messages. E.g, inside the DataTable's handleOnCancel function:

...
console.log("Cancel button was hit - call setAllSelectedState");
console.time("setAllSelectedState");
const output = this.setAllSelectedState(state, false, this.getFilteredRowIds());
console.timeEnd("setAllSelectedState");
return {
  shouldShowBatchActions: false,
   ...output
};

[github-actions]

DCO Assistant Lite bot All contributors have signed the DCO.

[netlify]

✅ Deploy Preview for carbon-components-react ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	9dbe3fe
🔍 Latest deploy log	https://app.netlify.com/sites/carbon-components-react/deploys/646e320460eb7c00083fd0c6
😎 Deploy Preview	https://deploy-preview-13831--carbon-components-react.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[netlify]

✅ Deploy Preview for carbon-elements ready!

Name	Link
🔨 Latest commit	9dbe3fe
🔍 Latest deploy log	https://app.netlify.com/sites/carbon-elements/deploys/646e32041ea059000873300c
😎 Deploy Preview	https://deploy-preview-13831--carbon-elements.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[mrspeaker]

I have read the DCO document and I hereby sign the DCO.

[tay1orjones]

@mrspeaker Thank you, this is great! 🎉 This will also close #4338, I've already updated the issue body to reflect this.

Do you think we could speed it up even more by not relying on reduce and just using a for loop instead to build up the rowsByID?

[mrspeaker]

Do you think we could speed it up even more by not relying on reduce and just using a for loop instead to build up the rowsByID?

@tay1orjones - strangely, I thought the same - but when I tested it the for loop was ever-so-slightly slower! I'm not sure why (and I bet it's browser specific), but in either case the time for the loop itself is negligible compared to the loop body. I decided to keep the reduce there to more closely match the coding style of the code base.

[tay1orjones]

@mrspeaker Very interesting, thanks for testing it out!