IE8 Optimizations?
IE8 Optimizations?
kombat
Posts: 15Questions: 5Answers: 0
We're considering phasing out the use of DataTables because it has performance problems with IE8. We know it isn't DataTables necessarily, but that IE just sucks, but I really like developing with DataTables so I'm trying to fight this. We're using v 1.9.4, but I dropped in v1.10.2, and didn't see any different in IE8's memory usage. It's still using the previous API. Would the new API help at all or is all mapped to the same new code?
The problem seems to come about on pages that need to create new instances of a data table and IE just has problem with or just can't reclaim the memory and the usage just goes up and up. Are there any initialization steps I might be missing or ways of killing a datatable no longer needed that would help IE along here that anyone has had success with?
This question has an accepted answers - jump to answer
Answers
I find it rather strange that you're planning to drop Datatables because it doesn't play nice with a produce that Microsoft is dropping support for.
The question is what would you replace it with - the main alternative would be a combination of YUI and their Datatable, which I suspect would have similar issues.
In answer to your question, the old and new API map to the same functionality. I believe in most cases the new API is quicker because the old functionality makes calls to the new API to work e.g. fnUpdate makes several api calls to work
Unfortunately, we don't get to choose the company standard browser. But hey, we're upgrading to IE9 next year. I love the company I work for but being a web developer, how far behind we are with IE presents a major problem for us. IE9 isn't going to help us much I'm afraid. They're phasing in Chrome as the standard, but IE is still something we'll have to deal with.
Someone I work with is proposing letting knockout apply the data, but use datatables' paging functionality. I have no idea at first thought how that would work but he's already doing it and will present it next week.
Other way around. The old API is a shim layer onto the new one!
Can you give us some details about your use of DataTables? Are you ajax loading the data and have deferred rendering enabled (which is by far the most efficient way for doing client-side processing in DataTables and leads to a noticeable improvement in old IE).
Allan
No problem.
We are using server-side processing. I'm not sure what deferred rendering is. I don't recall coming across that anywhere in the docs.
The particular page I'm working on now is using the detail row pattern noted in a blog post here. The main table using server-side processing with paging, sorting, and filtering. In the detail row there are 3 more datatables. When the detail row is opened, an ajax call is made retrieving all of the data needed for the 3 detail datatables. These are simple, not using paging, sorting, or filtering.
I've noticed with IE by looking at Task Manager, the memory usage for IE increases by about 20k everytime a detail row is open and a previously open one is closed. I've tried using fnDestroy() on them when closing a row but it didn't help.
Deferred rendering:
If you are using server-side processing already, then that is the most efficient way to use DataTables in terms of memory usage on the client-side. I'm very surprised that you are having memory issues with it.
It might be worth trying
row().child().remove()to destroy the child row. You could usepreDrawCallbackto run that method on any child rows shown in the table just before a draw.Allan
Deferred rendering is only generating the HTML for visible rows (in a paged/filtered view). See the link for more information.
Incidentally IE8 has (allegedly) poor Javascript memory management - I suspect it is more likely to be an IE8 problem than datatables itself.
I completely agree Vogomatix.