mui / mui-x

MUI X: Build complex and data-rich applications using a growing list of advanced React components, like the Data Grid, Date and Time Pickers, Charts, and more!
https://mui.com/x/
4.56k stars 1.33k forks source link

[data grid] Measurement runtime performance #2175

Open DanailH opened 3 years ago

DanailH commented 3 years ago

Summary 💡

Some time ago I made some effort to create a snapshot of the current performance state of the DataGrid and XGrid based on a couple of parameters.

Motivation 🔦

This ticket is aimed to provide visibility into those metrics and also for a place to track future progress and update the measurements. In the future, it will be probably beneficial for us to take those measurements as part of the pipeline and catch performance regressions before we ship the code.

To give an overview of what I used as base configuration for the grid:

function DataGrid100() {
  const { data } = useDemoData({
    dataSet: 'Commodity',
    rowLength: 100,
    maxColumns: 20,
  });
  const pagination = {
    pagination: false,
    autoPageSize: false,
  };

  return (
    <div style={{width: '100%', height: 500}}>
      <DataGrid
        {...data}
        {...pagination}
        checkboxSelection
        // localeText={bgBG.components.MuiDataGrid.localeText}
        components={{
          Toolbar: GridToolbar,
        }}
      />
    </div>
  );
}

Here for each DataGrid and XGrid they are variants with 100, 1000, 10000, and 100000 rows and with and without pagination enabled (keep in mind that DataGrid having more than 100 rows the pagination will automatically kick in).

The versions used are as follows:

"@material-ui/core": "^4.11.4",
"@material-ui/data-grid": "^4.0.0-alpha.30",
"@material-ui/x-grid": "^4.0.0-alpha.30",
"@material-ui/x-grid-data-generator": "^4.0.0-alpha.30",

Below you can find information about what has been done. Let's begin.

Examples 🌈

DataGrid100

Performance measurements with 100 rows (without pagination)

Performance measurements with 100 rows (with pagination)

DataGrid1000

Performance measurements with 1000 rows

DataGrid10000

Performance measurements with 10000 rows

DataGrid100000

Performance measurements with 100000 rows

XGrid100

Performance measurements with 100 rows (without pagination)

Performance measurements with 100 rows (with pagination)

XGrid1000

Performance measurements with 1000 rows (without pagination)

Performance measurements with 1000 rows (with pagination)

XGrid10000

Performance measurements with 10000 rows (without pagination)

Performance measurements with 10000 rows (with pagination)

XGrid100000

Performance measurements with 100000 rows (without pagination)

Performance measurements with 100000 rows (with pagination)

Final thoughts 🙏

First of all, if you have made it here - thank you 😅. It's quite a long description. What is left to be done is to benchmark how competitors such as AG Grid are scoring in similar configurations so we know where we sit in terms of performance.

All the code is in my own repo but we cal always move it. You can check it here -> https://github.com/DanailH/mui-datagrid-measurements

oliviertassinari commented 3 years ago

@DanailH Thanks for opening the issue. A couple of thoughts:

a. "Bundle size". I think that we should ignore the notion in this issue. We have #37, to first measure it continually on each PR. Then #18 with the actionable steps to improve. So far, we got little upvotes on the issue, so I'm not sure that people care. We could learn more in a future survey. I suspect that we could do a lot better. b. "First contentful paint". The value is, all the same, we also don't support SSR. I don't see why that this dimension would matter going forward. I propose we ignore. c. "Time to interact". I think that we could improve the way we measure it. We currently include in the measure the time it takes to build the test data set. This adds variance in the measures. d. https://www.crankuptheamps.com/blog/posts/2020/01/23/grid-comparison-2/ a comparison blog post to evaluate the "best" data grid. The blog post is significantly biased. Since when "best" is 80% about the performance? But maybe it's a pain that many end-users experiences and has grown as a differentiator 🤷‍♂️

Regarding the next step. I think that we should create a PR with a new benchmark folder as we have in the core that is automated (not in the CI). I would propose we measure based on d. :

  1. Time to first render, excluding the time to generate the data set
  2. Measure FPS with slow scrolling
  3. Measure FPS with fast scrolling
  4. Memory usage for loading the data set
  5. FPS for streaming data

We could also add a few bonuses:

As for how we measure, we can copy the infra we have in the main repo. We can also look into the automated benchmark created by @Janpot in https://github.com/mui-org/material-ui-x/issues/1933#issuecomment-874074947. There are also probably more examples to copy from online.

@DanailH How does it sound? Do you want to continue the effort?

DanailH commented 3 years ago

@oliviertassinari sure I can pick this up on the side and do the automated measurements as a follow-up.

AndrijBartenev commented 3 years ago

You are doing a great job, but it looks like it's better to split the scrolling into two parts: horizontal and vertical. I've just noticed that fps is much better for vertical scrolling, and not that good for the horizontal one.

m4theushw commented 3 years ago

@AndrijBartenev In the latest beta release, we introduced a new virtualization logic. Now both vertical and horizontal scroll should run at the same FPS.