[data grid] Bad scroll performance when displayed in larger viewports

[ceisele-r]

The problem in depth

In general, this applies to different browsers. Behavior slightly varies between browsers, but in general it applies to all browsers.

When viewing the (small) Pro/Premium Grid Demo with 100.000 rows in the docs in Chrome, it has a smooth scroll performance.

However, when opening the demo in CodeSandbox, the scroll performance becomes laggy.

This gets even more laggy when opening the demo in a separate window via the top right button

When scrolling in the full-width grid in a new window, it is really laggy.

Unfortunately, I cannot compare it to Stackblitz as I cannot open the Grid in a separate window there as the demo does not load in the separate window.

The (small) demo in the docs also gets worse performance if I increase the width & height of the displayed grid (via browser devtools). It no longer feels really smooth.

Therefore I am wondering if that's the best performance we can get out of the grid at the moment or whether it is possible to reach a smooth scroll behavior even if a grid is displayed full-screen on a regular 1920px width screen?

Your environment

Used CodeSandbox demo.

`npx @mui/envinfo`

``` System: OS: Windows 11 10.0.22631 Binaries: Node: 22.8.0 - C:\Program Files\nodejs\node.EXE npm: 10.8.3 - ~\AppData\Roaming\npm\npm.CMD pnpm: 9.10.0 - ~\AppData\Roaming\npm\pnpm.CMD Browsers: Chrome: 129.0.6668.90 Edge: Chromium (126.0.2592.87) ```

Hardware details

``` Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz 48,0 GB RAM Samsung 970 SSD Intel(R) UHD Graphics 630 ```

Search keywords: grid demo performance Order ID: 87798

[michelengelen]

Hey @ceisele-r this comparison is a bit "unfair", since CSB and Stackblitz will run a dev build with HMR, so it is naturally a lot less performant than a prod build. The only thing that feels weird is the mention of our docs having the same sluggish behavior. I couldn't really reproduce a laggy behavior myself, only when I enable CPU throttling.

[michelengelen]

I will try and run a production build and check back here

[ceisele-r]

Hi @michelengelen thanks, I was also thinking about the dev build vs production build in CSB and the dev build definitely performs much worse than the production build.

However, here is a screenshot of the profiler of one mouse wheel scroll in the "docs grid" (enlarged by removing/modifying the elements/css on the page):

Chrome's profiler is also telling there have been long tasks going on. Here is a dump of a (different) scroll profile - maybe it helps: Trace-20241008T155642.json

Also, here are two videos demonstrating the scrolling behavior (Chrome in Fullscreen - scroll via mouse wheel and dragging the scrollbar):

https://github.com/user-attachments/assets/344bb7f0-2e02-42d0-9c8c-0ff3d4cf4c6a

https://github.com/user-attachments/assets/2c559c50-aaab-4d37-b783-d51423458ad5

I hope you can see it in the video - it just doesn't feel really smooth.

[michelengelen]

@romgrk could you also have a look here? Thanks!

[romgrk]

The environment info isn't filled. Please refer to the new issue instructions to include env info. Please also include the hardware you're using so we have an idea what kind of performance to expect.

[ceisele-r]

@romgrk I added the environment info and hardware details to the issue above. However, as written above, this occurs with the demo page.

[MBilalShafi]

I gave it a quick test on the same Chrome version (129.0.6668.90) on Macbook M1 Pro 16GB RAM (running Sequoia 15.0) with no significantly sluggish performance for scrollbar (not even on CPU slowdown). Maybe it's more evident on Windows OS.

[michelengelen]

tested it on my windows machine as well and couldn't notice any sluggish behavior as well. That being said mine might not be that representative with

• Intel Core i7 10870 H
• GeForce 3080 RTX 16GB GDDR6
• 32GB DDR4 Ram

it is pretty naked software wise, so nothing running in the background as well.

Anything else we could test here @romgrk @MBilalShafi ?

[romgrk]

@ceisele-r By any chance would you be able to build an unminified production version of your app, and record a stack trace with that? I've looked at the trace you posted, I don't see anything abnormal other than the abysmal performance, but because it's minified it's hard to be reliably sure of what's happening.

If that's not possible we'll have to look into deploying an unminified production build somewhere to get a readable trace. CSB won't work, devmode makes React very slow.

[ceisele-r]

Hi @romgrk , here is a trace from an unminified production build: Trace-20241025T122959.json

Note that this is a pretty small grid - it only has 5 columns with ~700 rows.

I see quite some emotion code going on, probably that's one cause of the not ideal performance? Probably moving to pigment-css could improve it?

[romgrk]

The problem is the demo code, not the grid. MUI Material styling code is fairly slow and we've been working on mitigating that issue with the Emotion renderer, but indeed switching to PigmentCSS is the most optimal solution.

This should not be a problem for your code, as long as you author CSS in an efficient way (prefer static CSS objects to dynamic styles like theme => ({ ... }) or the sx prop).

For more context, the cells with a custom renderer that uses styled or sx are the main performance issue, so it makes sense that the docs demo feels faster: the initial visible viewport shows mostly text-only cells. And that's why large viewports feel much worse, they show the columns with slow cell renderers.

[romgrk]

We should probably re-write those renderers, the demo datasets are used at many places in the docs and give a bad impression of the grid's performance.

[Vagizova]

@romgrk

do i understand correctly that you want to make a perfect demo where everything will work perfectly, and not solve a problem? still, if i have a table on the whole page with some styles in cells and rows: the more rows the slower the scroll.

At the same time, we try to show as much as possible in the table, because for us it is a tracking and comparison tool, not just an accounting one.

On the other hand, i have an aggregation row (custom, with several fields, like min max average etc.) and in order to show it nicely, i have a renderCell on each cell, something like that:

renderCell: (params: RenderCellParams) => {
  if (isAutogeneratedRow(params.row)) {
    return <AggregationCell formatter={formatter} props={params} />;
  }

  return params.value;
},

while it would be cool to have separate methods for the aggregation row (i tried to describe it here does it make sense?)

on each cell the class name is also calculated (in fact, the value is simply taken from one of the fields of the row)

all together is slow, but if I change density to 'comfortable' (that doesn't suit us) scrolling becomes much better but if I set the row height to 25 (that suits us perfectly), set the aggregated row to auto height, then the scrolling is bad (we have then a lot: [Violation] 'scroll' handler took 225ms)

any suggestions? I would really appreciate any ideas

[romgrk]

If you have a problem with your own code, please post a reproducible example that showcases the performance issue. Your initial report only mentions the docs demo code which is slow for reasons that are unrelated to the datagrid code.

[ceisele-r]

@romgrk I think something got messed up here.

The report by @Vagizova is not directly related to my reported issue (we are different persons).

However, the trace I posted in the comment above ( https://github.com/mui/mui-x/issues/14876#issuecomment-2437621075 ) is a trace as you requested from our application ( as you requested in https://github.com/mui/mui-x/issues/14876#issuecomment-2430670016 ) where we see the performance issues (= not the demo/docs code).

I just mentioned in the initial report that the performance issue also occurs in the docs demo as I suspected it has the same root cause as the performance issues in our application.

But as you can see in my later comment with the trace ( https://github.com/mui/mui-x/issues/14876#issuecomment-2437621075 ), this issue also occurs in our own code (not using the demo code at all) with a pretty simple and small grid.

As @Vagizova now also reports performance issues, probably there might indeed be other issues with the grid (or the code using the grid) itself and not just the demo code as you mentioned here https://github.com/mui/mui-x/issues/14876#issuecomment-2440027383 .

[romgrk]

Missed that.

@Vagizova Please open a separate issue unless your issue is strictly the same.

@ceisele-r As I mentioned above, the root cause of the docs demo issue is not the datagrid. If you want us to investigate further, please provide a reproducible codesandbox with your own code.