Performance issue HTML/sScrollY

splinter03

Hey,

i've a performance issue with a DataTable that does not exceed the recommendations of 5000 records. It is a simple table width a dom-table as datasource. The zero-configuration with 2000 items is very fast (under my hardware-configuration: 800ms), also with bPaginate=false. But if i use html (span, a, etc.) in a td, the datatable slow down (1600ms). Not very fast, but ok. But if i enabe sScrollY and bScrollCollapse, the table needs more than 4000ms to render.

My questions:
1. Why html in a td slow down the datatable? Maybe internal type detection or text extraction?
2. Why is sScrollY so slow and how can i make it faster? Scroller or bPaginate=true are no options.

JSFiddle: http://jsfiddle.net/6HXX9/10/

Thanks for your help!

allan

> 1. Why html in a td slow down the datatable? Maybe internal type detection or text extraction?

The latter. The text needs to be pulled out so it can be used as part of the filter.

> 2. Why is sScrollY so slow and how can i make it faster? Scroller or bPaginate=true are no options.

Use Ajax loaded data. See: http://datatables.net/faqs#speed . Also use DataTables 1.10 which has a number of performance improvements.

Allan

splinter03

[quote] The latter. The text needs to be pulled out... [/quote]
Ok, disabling bSort and bFilter saves some time (200ms at a render time of 4000ms). Removing the html from the td saves more than 1100ms. That means disabling sorting and filtering don't prevent the text extraction?! Maybe a new setting where helpful to disable all that "magic stuff" for a specific column. What do you mean?

[quote] Use Ajax loaded data [/quote] It should work, but it is hard to implement, cause my real table contains input, checkbox and icons (action links, e.g. delete)...but i will test it next days...

[quote] Also use DataTables 1.10... [/quote]
I've updated my JSFiddle to the newest beta version, but no performance improvements http://jsfiddle.net/6HXX9/15/

allan

DataTables has to read the content of the cell if you are using a DOM source. It does that using `innerHTML` as that is the fastest option available. However, it is obviously going to be slower for the browser to execute when it needs to parse the DOM structure. That is will the majority of the speed hit comes when reading from a DOM source and why the FAQ recommends using Ajax loaded data when using larger data sets, since you don't then have that overhead - make sure you enable the bDeferRender option as well.

Allan

splinter03

Hey allan,

i've made a little test :) I've created a JSFiddle, same conditions as the first (table width 2000 rows). Extracting text from 16000 tds (2000 rows * 8 columns) takes with jquery 52ms, regardless of whether the cell contains html or not. So maybe there is some space for improvements?
JSFiddle: http://jsfiddle.net/hb79n/1/

Next days, i will check if ajax as datasource is faster under my conditions.

Thanks for your help!

allan

I don't doubt for a single second that performance improvements are possible. I've already spent countless hours working on them, and I'm sure I'll find more in future.

Doing a quick profile of your table:

20% of the time is spent doing width calculations
20% of the time is spent doing browser check (poor old IE...)
11% removing elements from the display
4.5% adding in the elements for the page
4.3% getting the nodes for each cell
3.6% getting the data for each cell

And a bunch of other stuff.

Any patches with performance improvements, or suggestions on where the improvements can be made in the code are very welcome indeed.

Allan

splinter03

Please do not misunderstand me, I will not complain. Its more my attempts to improve my datatable and i will share my thought with you.

20% for browser check...maybe an option to swith of these checks (e.g. for business-areas where i have the control over the browser and the version) = (rip ie 6-8) the new jquery-version also drops support for ie6-8...

And now the new results:
- under the same conditions, build in ajax isnt faster than dom as datasource.
Another interesting fakt: loading (external json request) the data into a js-array (and assign it via "data" to the datatable) is faster then the build in ajax.
- scrollCollapse is realy slow -> true: 8000ms, false: 4000ms

And here are the examples:
dom: http://jsfiddle.net/6HXX9/16/
ajax: http://jsfiddle.net/55uTL/6/ (buildTable1() = external ajax request, buildTable2() = internal ajax request)

Regards!

p.s. if i found some time i will dig into the datatables code.

allan

No misunderstanding - performance is extremely important! I have absolutely no intention of letting DataTables bloat up, so thanks for bringing this up!!

> 20% for browser check..

Yeah this one is very frustrating. Unfortunately, while it was introduced for old IE originally, actually it is used for all platforms / browsers now in order to calculate the scrollbar width. It could be made optional for when you aren't using old IE and aren't using scrolling...

> under the same conditions, build in ajax isnt faster than dom as datasource.

I'm extremely surprised by that. But then you have:

> 'paginate': false,

So deferred rendering is useless, since all rows need to be rendered up front. You can use Scroller if you need all rows to appear visible: http://next.datatables.net/extensions/scroller/

Also you are doing a lot of inefficient operations in the row callback, so that's going to be a large hit, particularly with all rows visible. Use `defaultContent` to add static content and `render` to do dynamic data. If performance is a concern, rowCallback should be avoided at all costs.

Allan

splinter03

Hey,

i tried it width render, but it isnt realy faster then rowCallback.
I looked at your code and i found out thant the following 3 functions consume more then 3/4 of rendering time: _fnScrollBarWidth, _fnCalculateColumnWidths, _fnScrollDraw

Especially setting/getting the height/width consume a lot of time, cause the browser is forced to redraw the ui. So the only performance improvement i see is to rearrange the code to minimize the mix of dom read/write actions or group these actions together. So that the browser can read all properties (as offsetHeight) and then write all changed properties. In this case the browser is not forced to read, write, read, write...
Maybe my description is a little confusing, so an example:

[code]
function _fnScrollDraw(settings) {
...
if (scroll.bCollapse && scrollY !== "") {
divBodyStyle.height = (divBody[0].offsetHeight + header[0].offsetHeight) + "px";
}
[/code]
Here you set directly the height of the scrollbody div. if we hold the height in a variable and set the height at the end where you set the scrollbody width...
[code]
// Apply to the container elements
divBodyStyle.width = _fnStringToCss(correction);
divHeaderStyle.width = _fnStringToCss(correction);
[/code]
...we can save 5 up to 10%! (not sure it works under all conditions because not the entire code between the two code-snippets was considered)

Michael

allan

I'm not sure it is quite as trivial as that unfortunately - the code for the scrolling does need to run in a very particular order, otherwise the scrollbar widths can be taken into account when they shouldn't be. There are a shocking number of edge cases in the scrolling. But this looks like a good place to continue the optimisation work that is always progressing :-)

Allan

splinter03

[quote]continue the optimisation work that is always progressing[/quote]
Sounds good :)
Another realy slow action i detected is wrapping the table (scrollbody...) with a div. Have you ever played with the idea to scroll the tbody (http://www.imaputz.com/cssStuff/bigFourVersion.html)?

I know it is a lot of hard work but i am happy to hear about any improvements.

Michael