Performance slow with 350 records and Scroller in Internet Explorer

dtkujawski

Any help would be greatly appreciated!! Here is a stripped down example:
https://jsfiddle.net/n30b0nkr/

In Internet Explorer this grid takes about 2s to render (much faster in Chrome, but still a bit slower compare to other grids which use virtual row techniques so that the entire table isn't updated to the DOM). I tried to turn on DeferRender but don't see a difference so I wonder if I have some settings incorrect. IE is a requirement of the users and some other grids, like SlickGrid or dhtmlXGrid are lightning fast but I can't seem to get DataTables to perform at the same speed). I assume I have it set up wrong, but not sure where to go.

Thank you in advance

dtkujawski

Here is a static file (no JSFiddle) that demonstrated the issue

allan

Thanks very much for the file.

There are three elements here that are taking time to process:

1. The custom widths
2. Scrolling
3. Scroller

The last two are the real killers in this case.

• The original test case was taking 5.14S for me to render.
• Without scrolling enabled and no custom widths defined and auto width enabled, it takes 270mS for IE to display the table for me.

The optimal thing from a DataTables performance point of view is always to not use scrolling. Almost all performance issues stem from that! Use paging instead. Scroller attempts to marry the two together, and it usually works, but it appears that IE has some performance issues with really wide tables. The more data, the more of an issue. This isn't a problem for other grids that don't use the table element since div positions are more easily calculated.

If you do require scrolling in the interface, use the scroller.displayBuffer option and set it to 1.5. This controls the number of rows that Scroller will actually pre-draw, allowing the deferRender option to improve performance since less rows need to be drawn at a time. This results in about 1S init time for me.

More generally, with scrolling because DataTables uses the table element, it needs to split the table into multiple parts, a table for the header, one for the body and one for the footer (if it exists). The widths are applied to the body which is slow, they then need to be read back in order to be able to apply them to the header. We can't just apply the same calculated values as it results in column misalignment!

Having said all that, it does look like from the trace that Scroller isn't acting as efficiently as it should and the table is actually being redrawn multiple times during initialisation. i suspect if I can identify why that is and resolve it the initialisation time will be halved - which I will look into. But it still won't be as fast as with scrolling disabled!

Regards,
Allan