Performance issues on release 3.1

[crushcafeteria]

Hey Oli, I think the 3.1 release has a performance bottleneck. I am not a JS guru but I made a video of the behaviour when rendering quite a large grid:-

SETTING UP THE TEST

Chromium Browser - Version 58.0.3029.110 System Performance Monitor: htop (sudo apt install htop) HP Core i7 8GB RAM,

See video below:- https://youtu.be/YMZKpgbgd8U

[olifolkerd]

Hey,

That looks like you are not using the Virtual DOM so it is trying to render in classic mode which will be very slow with big data sets.

To enable the virtual DOM you must make sure you set the height option in your constructor object, (this can be any valid CSS value)

$("#example-table").tabulator({
    height:"100%",
});

Let me know if that helps

Cheers

Oli

[crushcafeteria]

I have added the height but there is no change at all. Have also tested on Firefox, Chrome and Ubuntu Browser. The same result. I believe when setData is called during table initialization and loading of rows.

[olifolkerd]

could you try redownloading the 3.1 code, there was an issue with the first release which i fixed shortly after the release, so you might be running old code

also if you are creating the table while the element is hidden you will need to call the redraw function when you make it visible.

If that dosnt help could you post a copy of your tabulator constructor as i cannot replicate you issues this end.

Cheers

Oli

[olifolkerd]

Hey,

Just to let you know i have i got to the bottom of this issue, it is a cumulative effect that only becomes apparent in tables that take up most of the screen and contain a large number of rows. The small amount of time it takes to render a cell adds up to a lot in bigger tables and hurts scrolling performance.

I have profiled the rendering process and identified several areas where it can be optimised, i should have an update released this week to dramatically improve the rendering efficiency on larger tables.

Cheers

Oli

[crushcafeteria]

That will be a welcome addition. I made a temporary fix by moving my SQL server to another box and caching my queries. Good luck man

On Jul 5, 2017 10:01 AM, "Oli Folkerd" notifications@github.com wrote:

Hey,

Just to let you know i have i got to the bottom of this issue, it is a cumulative effect that only becomes apparent in tables that take up most of the screen and contain a large number of rows. The small amount of time it takes to render a cell adds up to a lot in bigger tables and hurts scrolling performance.

I have profiled the rendering process and identified several areas where it can be optimised, i should have an update released this week to dramatically improve the rendering efficiency on larger tables.

Cheers

Oli

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/olifolkerd/tabulator/issues/387#issuecomment-313018724, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwdMNEq_i49alMe5EjL7u66f9eRLJ4xks5sKzTEgaJpZM4N__Zb .

[olifolkerd]

The rendering_performance_improvements branch now contains a much faster renderer.

let me know your thoughts

[crushcafeteria]

Hey Oli, Your performance tweak works great. I can now render large dataset blazing fast. I also stumbled upon the cause of my 'other' performance issue. I use Laravel Debugbar for the nice stats. My class was doing close to 9000 queries and Debugbar was dumping all these logs (about 8MB) into my page. Thus the whole system going comatose for a bit. Disabled Debugbar for this page and it works like new. I might suggest mentioning this Debugbar quirk when using Tabulator in the official docs. Alot of my buddies use Debugbar and someone might run into this issue in future Thanks alot. I enjoy this grid