draw() way slower in 1.11.4 compared to 1.10.20

draw() way slower in 1.11.4 compared to 1.10.20

tntnettntnet Posts: 6Questions: 1Answers: 0

Description of problem:
I upgraded datatables from 1.10.20 to 1.11.4. In large tables the draw() is way slower. I have a event handler for "keyup change" on a input field, which triggers a search on a column and draw. Search returns quickly but draw takes long. The effect happens also when using the standard search field on the datatable.

Answers

  • allanallan Posts: 63,535Questions: 1Answers: 10,475 Site admin

    If you can post a link to a test case showing the issue, that would be great.

    If you are using rowCallback the issue might be there, particularly if you are displaying child rows.

    Allan

  • tntnettntnet Posts: 6Questions: 1Answers: 0

    Hi,
    yes, I created a very simple testcase. You can find it at
    for version 1.10.25 and for version 1.11.4. I shows the time in milliseconds between preDraw and draw events. The difference is significant and gets annoying with more data and firefox.

  • trongarttrongart Posts: 222Questions: 51Answers: 0

    I believe this is related to the same performance kill in this thread: https://datatables.net/forums/discussion/70909/huge-performance-decrease-after-updating-to-datatables-1-11-3#latest

    @allan Do you think this is something that can be fixed in 1.11 or is it an integral part of the updated library?

  • allanallan Posts: 63,535Questions: 1Answers: 10,475 Site admin

    Many thanks for the test case and yes - @trongart I think this is going to be related to the issue you are seeing (although not all of it).

    Could you each try this version: https://nightly.datatables.net/js/jquery.dataTables.js?312 ? (note the little anti-cache query attribute - the nightly gets cached by cloudflare and can take a little while to time out).

    That has this change which will make a nice little difference.

    Allan

  • trongarttrongart Posts: 222Questions: 51Answers: 0
    edited February 2022

    @allan Thank you so much for the updated nightly version. I applied it in the two relevant test cases from my message to you and unfortunately, I don't notice a performance improvement. Cache has been cleared completely and the nighly link added with the anti-cache attribute. Summarized the links in my direct message to you.

    @tntnet How is it looking on your end?

  • tntnettntnet Posts: 6Questions: 1Answers: 0

    Much better. I increased the dataset to 10000 entries. Entering something into the search takes about 10-20 ms with 1.10.25 and about 500 ms with 1.11.4. The new version is back to 10-20 ms. You can find it here :)

  • kthorngrenkthorngren Posts: 21,344Questions: 26Answers: 4,954

    @trongart, can you show us an example with the performance issue?

    I updated the examples from your thread and the fix seems to work:

    Original example with stateSave:
    http://live.datatables.net/vawetupu/1/edit

    Same example with the nightly code:
    http://live.datatables.net/vawetupu/3/edit

    Note there is an initial delay due to creating child rows for all 10000 rows in createdRow. You can see in the console how long it takes rowCallback to run for each page event.

    Kevin

  • allanallan Posts: 63,535Questions: 1Answers: 10,475 Site admin

    Excellent good to hear that helped @tntnet.

    @trongart Thanks for your PM - I'll take a look at it shortly.

    Allan

  • trongarttrongart Posts: 222Questions: 51Answers: 0
    edited February 2022

    @allan Added 2 test cases in our PM

    Using @kthorngren example:

    The performance kill is coming from the stateSaveParams function when I use a large number of filter buttons in 1.11 for state saving such as here (This has only 1 filter button, but I have more than 30 in my project): live.datatables.net/zibabete/11/edit
    Clicking on the button you can see it takes a while to process.

    The same test case, but with 1.10:
    live.datatables.net/voxifohu/1/edit
    Clicking on the button here produces results instantly.

    Commenting out stateSaveParams function in 1.11 brings the performance back in line with 1.10.

    @allan Do you think something can be done to optimise this in 1.11?

Sign In or Register to comment.