[data grid] Poor performance with TreeData and large dataset

[amannan-bucs]

Steps to reproduce

Steps:

1. Open this link to live example: Codesandbox Demo
2. Attempt the following interactions:

• Expand/collapse nodes within the TreeData.
• Scroll vertically through the dataset.
• Perform any editing or cell interaction within the grid.

3. Observe the performance lag and sluggish response times.

Current behavior

The DataGrid becomes significantly slow and unresponsive when interacting with TreeData on large datasets (50,000+ rows), even with virtualization enabled. Actions like toggling expand/collapse and scrolling are particularly affected.

Expected behavior

The grid should remain responsive and fluid during all interactions — including editing, scrolling, and expanding TreeData — even with large datasets. This is crucial for our production use case, where users frequently work with tens of thousands of records in real time.

Context

We are building a highly interactive data table that allows users to view, edit, and manipulate large datasets seamlessly. Performance is a critical factor for usability, and current slowness is a blocker in adopting this component for our needs. We expect virtualization to handle these volumes more efficiently.

Your environment

npx @mui/envinfo

  System:
    OS: Windows 11 10.0.22631
  Binaries:
    Node: 20.12.0 - C:\Program Files\nodejs\node.EXE
    npm: 10.5.0 - C:\Program Files\nodejs\npm.CMD
    pnpm: Not Found
  Browsers:
    Chrome: Not Found
    Edge: Chromium (135.0.3179.73)
  npmPackages:
    @mui/lab: ^6.0.0-beta.21 => 6.0.0-beta.21 
    @mui/styled-engine-sc: ^6.3.0 => 6.3.0 
    @mui/x-data-grid: ^7.23.5 => 7.23.5 
    @mui/x-data-grid-pro: ^7.23.5 => 7.23.5 
    @mui/x-date-pickers: ^7.23.3 => 7.23.3
    @mui/x-tree-view: ^7.23.2 => 7.23.2
    styled-components: latest => 6.1.13

Search keywords: data-grid-pro, data-grid-treedata, performance, large-dataset

Order ID: 102733

[arminmeh]

@amannan-bucs
I will investigate this further, but I am noticing that commenting out columns and groupingColDef props improves the performance a lot.
I would say that the problem is probably related to the custom cell renderers (group and actions).

[amannan-bucs]

Hi @arminmeh,

Thanks for looking into this!
You're right that removing columns and groupingColDef does improve performance a bit (not 100%)—but unfortunately, those are essential parts of our implementation. Custom cell renderers (particularly for grouping and actions) are necessary to meet our UI/UX and business requirements, so we can't remove them. Also, please note that in the actual case, I need to have such kind of more renderers to fulfil the business requirements.

Given that, I'd really appreciate any guidance on optimizing performance with these props in place. Are there known best practices or workarounds for improving render efficiency when using custom renderers with treeData? If there's anything that can help in this matter, we'd love to hear about it.

Looking forward to any further insights you uncover.

[michelengelen]

So, the main problem here is that you use state (isExpanded) to store the id of the expanded row. This triggers a full rerender and leads to the performance hit.

If you extract the grouping cell render:

const RenderGroupingCell = (params: GridRenderCellParams) => {
  const { id, rowNode, value } = params;
  const apiRef = useGridApiContext();
  const [isExpanded, setIsExpanded] = React.useState(
    rowNode.type === 'group' && rowNode?.childrenExpanded,
  );

  const handleToggle = React.useCallback(() => {
    setIsExpanded((prev) => !prev);
    apiRef.current?.setRowChildrenExpansion(id, !isExpanded);
  }, [apiRef, isExpanded]);

  return (
    <FlexBox alignItems={'center'} flex={1} margin={'0px -10px'} height={'100%'}>
      {rowNode.type === 'group' && (
        <IconButton onClick={handleToggle}>
          <ExpandMoreIcon
            sx={(theme) => ({
              fontSize: 20,
              transform: `rotateZ(${isExpanded ? 0 : -90}deg)`,
              transition: theme.transitions.create('transform', {
                duration: theme.transitions.duration.shortest,
              }),
            })}
            fontSize="small"
          />
        </IconButton>
      )}

      <Typography fontSize={14} sx={{ ml: 1 }} fontWeight={600}>
        {value}
      </Typography>
    </FlexBox>
  );
};

... and use IconButton instead of GridActionCellItem ... you can then listen on the 'rowExpansionChange' event with gridApiRef.current?.subscribeEvent(...) and store it in a ref instead.

With this the bottleneck should be gone

[amannan-bucs]

@michelengelen I've implemented the solution you suggested in your last comment. Unfortunately, it hasn't significantly improved the performance lag we're experiencing.

We're using expandedRowId because our grid is editable. When a row enters edit mode or an update is made, the expanded row collapses due to a re-render happening behind the scenes. To avoid this behavior, we need to explicitly manage the expanded state of the group.

Please take a look at the updated code in the live demo, which reflects your recommendations. Since the performance hasn't improved noticeably, I'd appreciate it if you could take another look and let me know if there are any other potential bottlenecks or optimizations we might be missing.

Thanks!