Skip to content

fnAddData can be slow when adding many javascript objects #50

Closed
wants to merge 3 commits into from

2 participants

@bmac
bmac commented Feb 26, 2012

I've observed that the use of $.extend inside fnAddData can be slow when adding many (hundreds or thousands) of javascript objects especially in IE8.

This pull request adds a flag to datatables to disable the use of $.extend inside fnAddData as a performance improvement.

@DataTables
Owner

I 110% agree with the change to how the oData object is created - extending with the already cloned data is daft. I've just committed a change that addresses that: 5479600.

Regarding the flag and cloning the data. I'm very reluctant to add a flag for this as I think it will serve to ultimately confuse. However, I absolutely see the need for it to bypass the extend. I'm actually wondering if an independent copy of the source data is required.

I'm very much inclined to say no, it isn't needed and just use the passed in array/object, rather than copying it.

Looking back through the DataTables source code, I've done a slice on array data right from the very start (1.4+, 1.3 and before got it wrong...!), and then continued the basic idea when object support was added.

The only time I can see this being an issue is with data is added by fnAddData and the developer using the method then uses that same array/object to do something else, or the same issue when passing data in using aaData on initialisation. Indeed it is actually a pointless overhead a lot of the time at the moment (DOM, server-side processing).

Will think on it some more, but I suspect I'll be making that change for 1.9.1. Your thoughts on it would be very welcome :-)

@DataTables
Owner

DataTables 1.10 is going to remove that $.extend / slice when adding data, which is only needed because of fnRender, and fnRender is going to be removed in 1.10. That will probably be one of the first commits I make when starting on 1.10 development (not far away now - just 1.9.4 to get out the door first).

As such a bCopyData flag is no longer needed since the data will never be copied now. Going to close this pull request as a result.

@DataTables DataTables closed this Sep 16, 2012
@DataTables DataTables added a commit that referenced this pull request Feb 9, 2016
@DataTables Fix: Clear the cached data setter for DOM sourced tables when setting…
… column options. This fixes issues with ColReorder and DOM sourced tables

- Fixes DataTables/ColReorder #50.
4ce6614
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.