Tabulator: Performance issues on release 3.1

Created on 20 Jun 2017  Â·  7Comments  Â·  Source: olifolkerd/tabulator

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

Bug

All 7 comments

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

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.

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

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

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
.

The rendering_performance_improvements branch now contains a much faster renderer.

let me know your thoughts

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jiaqianliCn picture jiaqianliCn  Â·  3Comments

tomvanlier picture tomvanlier  Â·  3Comments

yaxino picture yaxino  Â·  3Comments

aballeras01 picture aballeras01  Â·  3Comments

tomheaps picture tomheaps  Â·  3Comments