DataTable performance issues

[mohan1304]

Current behavior

Observing below issues with DataTable

1. DataTable performance is very slow when table has more rows. Observed somewhat better performance up to 500 rows and 1000 rows is ok and after that it is very slow and also it freezes the screen
2. Opening and selecting value from MutiSelect filter of table columns is very slow
3. Resize of table columns is very slow

Expected behavior

1. Table performance should be improved and it shouldn't freeze the browser at any point of time
2. Performance of Multi select dialog display should be improved when we click on table column header with mutiselect filter
3. Performance of Select/Unselection of a value from mutiselect filter should be improved
4. Column resize performance also should be improved

Minimal reproduction of the problem with instructions
DataTable with 10 columns and each column has multiselect filter with column data as filter options. Performance issue can be observed when number of rows increases. try with 500, 1000, 1500, 2000, etc... rows

What is the motivation / use case for changing the behavior?

Please tell us about your environment:
Operating System: Windows 7

• Angular version: 2.0.X

Angular 2.4.6

• PrimeNG version: 2.0.X

PrimeNG : 2.0.0

• Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

Chrome 56.0.2924.87 (64-bit), IE11

• Language: [all | TypeScript X.X | ES6/7 | ES5]

• Node (for AoT issues): node --version =

[pandamorphism]

Probably this is a result of removing trackBy function. Please, return it. We can`t migrate to newer version because of that.
808d95a#diff-693f413104a81c421843ae657f5a6d09

[cagataycivici]

But trackBy causes a problem, leaving it empty breaks the table and data does not change.

[nathanrobinson]

why not have a default trackBy if it is left empty?

[Nattujessy]

Referencing similar issue #1877

[itsheng]

If the table needs to render many columns, we can see the same performance issue.
Following is the code I use to test datatable performance.

        let cols = 1000;
        let rows = 10
        this.headers = Array.from(Array(cols), (_, i) => { 
            return { "field": "column" + i, "header": "Column" + i, "style": {'width':'100px'} } 
        });
        this.data = Array.from(Array(rows), (_, i) => {
            let result = {};
            this.headers.forEach(h => {
                result[h.field] = i;
            })
            return result;
        });

[Ketec]

Noticed performance issues as well - some of our tables can be 22k row (with pagination).
But even smaller 1-2k rows are slow. Selecting a row has noticeable delay (if checkcolumn is enabled i can see up to 1s delay before it is checked).
Rapidly selecting rows can end up freezing the browser as memory usage also skyrockets.

[kgkern01]

I am seeing the same issues, with even 100+ rows being returned it freezes the browser. I'm even using server side pagination, so the API is only returning 100 rows, and returning within about 1s. This is using Angular2 and a local API as well.

[cagataycivici]

Thanks we will review.

[ghost]

RowTrackBy has been added in 4.0.1 by #2633

[kgkern01]

How is rowTrackBy used?

[cagataycivici]

Same as ngForTrackBy, consult the docs of Angular please.

[kgkern01]

Using the rowTrackBy made my datatable slower. I am only loading 200 rows at a time from the server using pagination. The table is then only 375px showing about 15 rows at a time and 7 columns. Without rowTrackBy is about 6 seconds for a row click to highlight the row, with rowTrackBy it increases to 7 seconds for the row to highlight. I am using version 4.0.1 with Angular 4.1.3. The rest of the browser functions are very slow as well with only 200 rows. Below is the function I am calling from [rowTrackBy] with the table being a collection of "parts".

trackRow(index: number, part: Part): number {
return part.partId;
}
Why would only a 200 row table slow the browser down so significantly? With 50 rows it functions great.

[cagataycivici]

Provide a plunkr please.

[cyberrranger]

same problem
demo with 50 entrys
http://plnkr.co/edit/ncVnlRcDeYiIbOen5c3y?p=preview
select a entry is fast

demo with 500 entrys
http://plnkr.co/edit/7h0cfPLhPGdoluWTw6YC?p=preview
select a entry is slow

[cagataycivici]

Thanks we will review for 4.0.3.

[jamesdking]

+1 for this. Just tried to use it with 2000 rows, and it is very slow taking > 5 seconds to render the table once the data is loaded, and row selection, editing fields etc... are unresponsive.

http://plnkr.co/edit/ZOwiNr9D6p003rtNYFM3?p=preview

[cyberrranger]

the same performence Problem with p-accordion

<p-accordion [multiple]="true" class="ui-g-12">
<p-accordionTab header="BLUBB">
<div class="ui-g">
</div>
</p-accordionTab>
</p-accordion>

[cagataycivici]

It is better to divide each case of DataTable into separate tickets for example, we've added a performance boost for selection in;

#3101

Other one is;

#3102

We're trying the best we can do from our side, however for 1K+ rows the number of bindings increase so we may hit a wall. I'd suggest pagination if that is acceptable. In the end, lazy or non-lazy, pagination can deal with large datasets or virtual scroll.

Closing as we're adding different tickets for each improvement.

[jamesdking]

Appreciate all your efforts working on this project, I know it must be a lot of work.

Quick question around the 1000+ rows performance impact: Do you know if there something fundamentally different about some of the other Angular grids that do seem to be able to handle a lot more data? E.g. if you look at http://demos.wijmo.com/5/angular/benchmark/benchmark/#/flexgrid you can load 1 million rows into some of the grids seemingly without any significant performance penalty.

[cagataycivici]

That example does not really render 1000+ rows, it is similar to the VirtualScroll mode of DataTable which again same as pagination. I'd like to see what happens when you push 1000 rows to the dom.

[cagataycivici]

We're still digging this, it seems number of columns has a huge factor, I've tried code of @cyberrranger with 2000 rows on 3 columns and result is quite acceptable. Increasing columns significantly slows down it, I've then removed all the column content like editable cells or so and just kept simple readonly content to display the column field value which resulted in 2000K rows with 9 columns perfoming really well, no delays on mouse interactions. I think we've found our bottleneck.

[eilon-shai]

we are facing a real performance issue even when the table contains only few rows, compiling in dev mode the only issue is with the reordering of the column that work very slow.
when compiling in prod mode all table become not responsive

[cagataycivici]

Please provide a plunkr that simulates your case and we'll review.

[pandamorphism]

This happens because of DataTable add dragover listener to DOM and huge amount of dragover events trigger detect changes cycles. So, if you have low optimized application it will be suffer while trying to reorder columns. Especially in dev mode.
Here is my pull request that optimize dragover handler making run it outside of angular and not provoking detect-changes cycles. dd40ddd

There is also bottleneck: functions that cause paint reflow are called in dragover handler which triggers huge amount of paint reflows
this.domHandler.getHiddenElementOuterWidth(this.reorderIndicatorUp) this.domHandler.getHiddenElementOuterHeight(this.reorderIndicatorUp)
fix is here: 4d59cf2

[eilon-shai]

Hi Oleg, thanks for your reply, when this change will be available on version that I can pull from npm? Eilon

…

On 13 July 2017 at 00:56, Oleg ***@***.***> wrote: This happens because of DataTable add dragover listener to DOM and huge amount of dragover events trigger detect changes cycles. So, if you have low optimized application it will be suffer while trying to reorder columns. Especially in dev mode. Here is my pull request that optimize dragover handler making run it outside of angular and not provoking detect-changes cycles. dd40ddd <dd40ddd> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2023 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQmwpGSzLfSW4RZqurOxM1f3nIbtBgDlks5sNUD-gaJpZM4L7WCZ> .

[pandamorphism]

Hi Eilon,
this question is for guys from PrimeNg, i don`t have rights to merge to master. But you can test fixes above using forked version "primeng-ua": "^4.1.0"

[eilon-shai]

thanks Oleg, great solution works like charm

…

On 13 July 2017 at 11:32, Oleg ***@***.***> wrote: Hi Eilon, this question is for guys from PrimeNg, i don`t have rights to merge to master. But you can test fixes above using forked version "primeng-ua": "^4.1.0" — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2023 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQmwpJjSX2_xBCDpwoyJV-8yF6n6HeLUks5sNdYWgaJpZM4L7WCZ> .

[cagataycivici]

Merged, thank you. Performance gain is significant!

[pantonis]

Is there any example on how RowTrackBy is used?

[srh-ocean1991]

I'm using primeng datatable from latest version 4.2.2 but there is still huge performance problem.
I have some columns with ng-template but even when I removed them and use datatable with 8-10 column and 900 rows my application slow down significantly.
I tried RowTrackBy too.

  <p-dataTable [value]="values" id="vTable" [paginatorPosition]="'both'" [rowTrackBy]="rowTrackBy"
               styleClass="ui-datatable-hor-scroll" (onRowClick)="goToDetail($event.data)"
               [paginator]="true" [rows]="rowCount" [rowsPerPageOptions]="[10,20,50,100,500,999]"
               [responsive]="true" [enableLoader]="true"
               [lazy]="true" (onLazyLoad)="loadIfxesLazy($event)"
               #dataTable>

[Ketec]

Iv noticed in the code that there are places where property is bound to methods - like isSelected().
This is bad because it causes angular to trigger and run over those methods insane number of times every second. Change detection triggers on any click - even mouse hover etc.
A thousand row table could easily trigger it tens of thousands of times every second.
So it does all the comparing/method calls/logic every single time. And currently it does not check properly for empty selection.
if (this._selected) is true if it is a empty array. This needs length check, value assigned to a property that is updated when selection changes.
There may be more places like this.

[ctrl-brk]

In my case datatable with ~3000 rows is not practically useful at all. The whole browser becomes unresponsive with any key press.

[srh-ocean1991]

I realized that if you enable production mode in application, performance of datatable will significantly improve !
enableProdMode(); in main.ts

solved my problem.

[harveenchadha]

I have a Datatable with 2200 records with 12 columns and even after doing all the things mentioned in this thread, It is still lagging like anything. Scrolling takes 4-5 seconds and binding of the grid itself takes 40-50 seconds.

[JordanDurieux]

Really waiting for the TurboTable !

[jyothipallati]

Hi , can you please let me know hot to download "primeng-ua": "^4.1.0" jar

[cyberrranger]

@jyothipallati primeng ist not with Java (.jar), here we use Typescript (.ts)

[IgorKurkov]

Are any updates on performance optimizations with primeNG table? 500 rows blocks screen for a 4sec