Rendering many (~100) small (1-10 row) tables very slow, unresponsive with date.js

Rendering many (~100) small (1-10 row) tables very slow, unresponsive with date.js

WeaponX86WeaponX86 Posts: 40Questions: 0Answers: 0
edited November 2012 in DataTables 1.9
I created this test case, but jsFiddle multiplies the render time by a factor of 4:
http://jsfiddle.net/r7ZbZ/5/

~30 s (Without date.js loaded)

So here is the standalone script:
http://pastebin.com/Pjp2UjSn

Using the Firebug profile function with 93 tables:
~1.8 s (Without date.js loaded, auto-width false)
~8.5 s (With date.js loaded, auto-width false)

~2.3 s (Without date.js loaded)
~8.8 s (With date.js loaded)

Sometimes I get:
"A script on this page may be busy, or it may have stopped responding. You can stop the script now, open the script in the debugger, or let the script continue."

The profiler shows date.js taking up the largest percentage:
[quote]
Function Calls Percent Own Time Time Avg Min Max
File
anonymous 37709 19.24% 1651.599ms 2243.466ms 0.059ms 0.001ms 139.266ms
date.js (line 48)
anonymous 9945 15.99% 1372.331ms 16067.72ms 1.616ms 0.003ms 9169.008ms
date.js (line 56)
anonymous 14240 11.84% 1016.121ms 3730.154ms 0.262ms 0.001ms 141.049ms
date.js (line 55)
anonymous 28829 11.72% 1006.402ms 3172.545ms 0.11ms 0.005ms 139.445ms
date.js (line 79)
anonymous 3701 6.23% 534.885ms 16769.375ms 4.531ms 0ms 9206.652ms
date.js (line 69)
anonymous 8376 5.46% 468.576ms 3347.434ms 0.4ms 0.003ms 3.075ms
date.js (line 59)
[/quote]

Now, the strange part. I removed all of the date columns and date.js still immobilizes the script. Any ideas?

Replies

  • allanallan Posts: 63,498Questions: 1Answers: 10,471 Site admin
    Good grief - that page absolutely kills my i7 processor :-(.

    Having 100 odd DataTables on the page probably doesn't help. Is that what you intended?

    Allan
  • WeaponX86WeaponX86 Posts: 40Questions: 0Answers: 0
    edited November 2012
    Well the tables are in a nested tree. The plugin I am using for the tree rendering doesn't support branch opening callbacks so I have to load the entire thing at once. I might be switching to jsTree to solve that.

    The primary issue here is that DataTables seems to attempt to parse every field into a date which is very expensive. Having date.js included amplifies this overhead due to it extending the native parse function. Because of this I'm having to drop date.js in favor of moment.js until I figure out a different solution.
  • allanallan Posts: 63,498Questions: 1Answers: 10,471 Site admin
    > The primary issue here is that DataTables seems to attempt to parse every field into a date which is very expensive

    Doing a native Date.parse() is a very fast operation. If date.js is overriding the build in Date object (urgh!), then all bets are off, since it will be doing regex lookups etc on every call.

    Allan
  • WeaponX86WeaponX86 Posts: 40Questions: 0Answers: 0
    Is there any way I can specify in aoColumnDefs the fields that are dates rather than having DataTables indiscriminately try to parse every value in every column as a date?
  • allanallan Posts: 63,498Questions: 1Answers: 10,471 Site admin
    Yes - use sType .

    Allan
This discussion has been closed.