Replies

• braz Posts: 12Questions: 0Answers: 0

  July 2009

  Hi allan,
  
  Thanks for new release. Hope more attention will be paid to DOM manipulation perforamnce in big tables in future releases.
  
  I have one question:
  
  you wrote in release notes:
  "Fixed: A small change to how the filter value is set on initialisation to take account of the back button and webkit browsers"
  
  Will it help me somehow in this problem http://datatables.net/forums/comments.php?DiscussionID=301&page=1#Item_3
  
  I'va already implemented a fix via cookies, but it would be better to use smth internal.
• allan Posts: 61,972Questions: 1Answers: 10,160 Site admin

  July 2009

  Hi braz,
  
  Regarding your question about the fixed comment - the issue was simply that Webkit browsers were not setting the filter input box back to "" (i.e. blank), but it was filtering as if the filter was blank... So the fix was just to remove the old value. As such I don't think it will help with your problem there. If you have a fix via cookies - I'd stick with that!
  
  Regarding the DOM performance - how big a table are you thinking of? The performance should be acceptable up to quite a large number (I'd very much recommend setting bSortClasses to false for large tables as this takes significant overhead!). Certainly, performance is key, and is there is an area which needs improving, I'd like to address it.
  
  Regards,
  Allan
• braz Posts: 12Questions: 0Answers: 0

  July 2009

  Hi allan,
  
  Big thanks for the tip about bSortClasses option, setting it to false decreased rendering time of my datatables almost twice. However, I wonder why this option is "true" by defaut, as for me it should be enabled only if user defines those additional classes in dataTable options.
  Now the performance is much better, on example my dataTable of 1000 rows and 6 columns with html cell content renders in 846ms in FF 3.5
• allan Posts: 61,972Questions: 1Answers: 10,160 Site admin

  July 2009

  HI Braz,
  
  Excellent stuff - good to hear that does the trick nicely. I did think that DataTables should cope reasonable well with 1000 rows :-).
  
  Regarding the bSortClasses option - yes indeed it is a significant drain on processing power, but it is enabled by default because I was generally expecting DOM interaction to be a fairly small table, with server-side processing used for much larger ones. It's difficult to gauge the correct defaults to pick when I don't have any direct feedback such as live usage monitors that you might get from a web-site, but I think this is the correction option in this case as the usage cases I have seen tend to fit my criteria above, and it's very easy to "flick the switch" if needed (such as in this case) :-)
  
  Regards,
  Allan
• braz Posts: 12Questions: 0Answers: 0

  July 2009

  Hi Allan,
  
  No problem with defaults, your documentation is full enough for figuring out correct settings to fit specific needs.
  
  Regarding server side processing, of course it is a good feature for big tables, but in case of using it the great part of dataTables idea is lost. As for me the biggest benefit of dataTables is that to make it work I only need to form JSON data on the server and send it to the client, everything else is done by dataTable. It is easy to integrate in existing big project where tables are used on many pages and data comes from complex SQL requests. In case of using your server side script I have to create some intermediate interface between dataTables and existing php scripts which implements sorting, filtering, and even if I only need to create a config with several SQL queries for each table I still have to write some code :)
  The second issue is server performance, I didn't performed any analysis, but I think too many ajax requests with db queries can increase server loading. On example filter feature sends ajax request after typing each new letter, so it produces several db queries in small time period and if this happens on big amount of data I think it can have influence on server performance. Actually it might be interesting to check dependency of server/client performance on big tables using server side and only client side.
  Anyway I understand that there is no other way to speed dataTables up than using server, so the best solution for me might be not using very big tables on the site :)
• allan Posts: 61,972Questions: 1Answers: 10,160 Site admin

  July 2009

  Hi Braz,
  
  All the points you make about server-side processing are bob on - and are the reason that support for this data source has only been added in v1.5. The previous releases all focused on the DOM (I think Ajax source was only added in 1.4 if I remember rightly...). I was worried about DataTables just becoming an empty events container, but I think it's added an extra demantion to DataTables which has proven to be exceptionally useful (to myself as well as others).
  
  The reason for including it however, is that DOM processing for 1'000'000+ rows would just kill a browser - but it's not unreasonable to want to show this amount of information in tabular format. In fact the server-side processing is a lot more extensible that just pulling data from the server - the way it is implemented actually allows pulling data from almost any source - for example an AIR or Gears SQL database in the browser/application, or some XML/XSLT transform. It does put emphasis on the the developer to write the server-side code, but this is the only way to allow DataTables to be platform neutral.
  
  Regarding the performance - totally agree here. To this end there has been a reasonable amount of work to stop DataTables DoS'ing your own server! There is a filtering plug-in from Zygimantas Berziunas from example which introduces a delay when filtering, and I've put together a pipelineing example to load a lot more data that is actually displayed to increase paging speed via a local cache.
  
  Hope this helps explain some of my design decisions.
  
  Regards,
  Allan