datatable construction slow when there are many rows of data

datatable construction slow when there are many rows of data

Yang.SongYang.Song Posts: 23Questions: 4Answers: 0

Here is the link to the test case. http://live.datatables.net/qawihawi/1/edit

I only loaded 1000 rows of data and the table has only a handful of fields. Imagine it's a wider table or the number of rows is 10 times...

We were using self created paging buttons so we turned off the paging from dataTables. The scroller works great except it takes a while to create the table and we can't really do deffered render.

Is there any suggestion on how to render the page faster? Are there insufficiencies that can be eliminated? Or is this the best we would get? Thanks!

Answers

  • allanallan Posts: 63,368Questions: 1Answers: 10,449 Site admin

    Your test is taking around 400mS to initialise and render the DataTable for me (Firefox on Linux). How long is it taking for you?

    The most sure fire way of speeding your table up is to not use scrollY. Also enable paging - that will let DataTable defer rendering of rows (which you currently have disabled) rather than drawing all 1000 rows up front.

    With those changes ( http://live.datatables.net/qawihawi/2/edit ) initialisation for me takes around 150mS.

    Allan

  • Yang.SongYang.Song Posts: 23Questions: 4Answers: 0

    Allan, were you running with performance tab or just click the reload?

    I put the html and javascript in one file - just copy the js and add a section to the HTML and save as an html file.

    When I used performance tab to profile, I got the below diagram. At 1000, it does not look too bad. But when more rows are loaded, it slows down pretty bad. I tried following the code but it's difficult for me to identify. One question I have is that _fnAddData() is called once for each row of data passed in. It in turn calls _fnCreateTr() to create the actual row in DOM. But why is _fnCreateTr() called multiple times for the same row? I counted - for each _fnAddData(), 16 _fnCreateTr() were called. I can't figure out how that loop happened or why. Could you take a look? I have attached both picture in this post. Thanks!

  • allanallan Posts: 63,368Questions: 1Answers: 10,449 Site admin

    Yes, I was using the performance profiler in Firefox.

    Did you try my changes? Those two changes I suggested are by far the biggest performance wins you can get.

    Allan

  • allanallan Posts: 63,368Questions: 1Answers: 10,449 Site admin

    Also _fnCreateTr has a condition in it that it will only create the row node if required:

    if ( row.nTr === null )
    

    Allan

  • Yang.SongYang.Song Posts: 23Questions: 4Answers: 0

    I'm looking into the possibility of adding the parameters you suggested. But it's more involved than just adding them. We have implemented screens with our own paging buttons where we don't retrieve all the data and do delayed rendering, but only retrieve the data requested for the page. We couldn't get that to work right with the parameters you suggested.

    I tried debugging through the code. But I don't see how _fnCreateTr() is being called 16 times. When I debug, it's only called once. but if each row creation calls it 16 times for a 8 column row, even if it only takes 1ms, it still adds up 1000x16x0.001. Where am I missing? Why is it called 16 times instead of once? Thanks!

  • allanallan Posts: 63,368Questions: 1Answers: 10,449 Site admin

    If it is - I don't know why. Have noticed that Chrome's inspector breaks up calls to a function because, so it looks like it is being called more than it is.

    As a little test consider this example: http://live.datatables.net/waceselo/1/edit .

    Put a breakpoint just inside the _fnCreateTr function then run the code. It is called only once.

    Allan

  • Yang.SongYang.Song Posts: 23Questions: 4Answers: 0

    That's the strange part. When I ran this in debugger, it called _frCreateTr only once. But when I ran using the profiler, it was loaded multiple times. And it ran much slower. Maybe it's the profiler doing something funny. We'll take a look at that screen and see if we can change the config to make it come up with less data. Thanks for your help!!!

This discussion has been closed.