mat-table performance issue with large amount of columns and editing

[psenechal]

Bug:

mat-table performance with 94 columns and 100 rows with inline editing is now extremely slow with v6. With v5, clicking a button to edit a row would render all the editing controls for that row within 1 second. After moving to v6, rendering those controls now takes 8-10 seconds and navigating the table is very slow.

What is the expected behavior?

Performance should be the same if not better than v5.

What is the current behavior?

It takes too long to render the editing controls in the row.

What are the steps to reproduce?

My apologies for the somewhat vague issue report here and I realize that we're really pushing the limits with a table of this size. I really just wanted to know if anyone is aware of a change from v5 to v6 that could be responsible for the performance issue and any possible workarounds. I did try adding trackBy which had no effect whatsoever on the poor performance. The table has 94 columns, each column is defined individually, not in an ngFor loop. Within each column cell definition are two ng-containers, one for display, one for editing. When the flag for editing is enabled, the ng-container that displays contains either a mat-input or mat-select for editing. Some cells contain mat-tooltips, but I removed all of those to make sure they weren't causing the issue (no change after removing).

What is the use-case or motivation for changing an existing behavior?

We would like to upgrade to v6 for the new features, but are stuck on v5 if we can't get the table to perform adequately. We're also looking at other datatable solutions for this particular table because it is so ridiculously large and complex.

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

Angular 6.0.6, Material 6.3.1, Windows 10, Typescript 2.7.2, tested in Chrome, Firefox, IE10

Is there anything else we should know?

Thank you for any assistance you may be able to provide

[mcailleaux]

Same problem with only 4 columns and about 20-30 rows elements inside each columns

[djleonskennedy]

@psenechal IE10? are u kidding man ?

[psenechal]

@djleonskennedy Corporate approved browser, so we have to test in that browser...even though nobody here actually uses it. Funny enough, it performed faster than Chrome but slower than Firefox for this example.

[hakimio]

Material 2 project doesn't support IE10 and Microsoft itself dropped support quite some time ago. I don't see why you expect it to work on IE10.

[psenechal]

The problem is in all browsers...I simply stated that I also tested it in IE10, not that I expected it to work in IE10. Everyone here uses Chrome, regardless of what the official corporate policy is.

[Eddygn]

I have a large table with columns of inputs, so far the only thing that made a difference is to set

changeDetection: ChangeDetectionStrategy.OnPush

and use ChangeDetectorRef
to manually update changes after any table updates

[mcailleaux]

The problem still persists with version 6.3.2

any idea ?

[djleonskennedy]

@psenechal For perfomance improvement i'd suggest

• ChangeDetection.OnPush
• user Pure Pipes with memoization
  more detail you can find here: https://blog.mgechev.com/2017/11/12/faster-angular-applications-pure-pipes-memoization-pure-functions-part-2/

also virtual scroll available in cdk-expiremental, you can try use it

however keep in mind material2 supports only 2 last version for browsers, Microsoft IE11, EDGE

Regards

[timplateus]

For people who are still having this issue:

I was working with a paginated table with 800 rows and +/- 20 columns, which took 16000ms to render.
The solution that helped me was found on Stack Overflow, which states that you have to bind your large dataset to the datasource after setting pagination and sorting:

this.dataSource.paginator = this.paginator;
this.dataSource.sort = this.sort;
// Binding the dataset comes last
this.dataSource.data = <YOUR DATASET>;

This reduced the HTML rendering to 400ms, a performance increase of 4000%!

[Swoox]

Sometimes people overuse the div tag try to use the ng-container tag more often this will result in better preformance. The divs will not be loaded in the dom anymore like crazy and that's affecting the performance.
I went from a form page loading from three seconds to under one second with this change.

[andrewseguin]

Some good recommendations have been given. Another improvement you can make is to only provide data to the table that you expect to be in the viewport. For data not expected in the viewport, you can send an empty object. Listen for scroll events to know when the data should be filled in