Memory leak related to child rows?

Memory leak related to child rows?

scottkmitch1scottkmitch1 Posts: 9Questions: 3Answers: 0
edited May 2014 in DataTables 1.10

Lets take a simple test case http://jsfiddle.net/b6fKf/2 Click on any row and a child row should appear with a bunch of DOM elements. Click on that row again and the row will be "hidden" via the hide method. Then force a GC. You can repeat this process and should notice the JS memory is growing. Using google chrome's developer tools you can take a heap snap shot and look at the Detached DOM tree. I would like help from the DataTable experts to analyze this but there are a bunch of the DOM elements that were just created. I am seeing that dataTableSettings is frequently referenced in the retainers window, but I am not an expert in JS memory tools and management in general.

What is the correct way to remove/destruct child rows such that all memory is made eligible for GC? I have seen the hide method and tracked that this method resolves to the __details_display function which appears to do a jquery remove and then also calls __details_events. Without fully analyzing the code it seems like there is some clean up going on, but are there other cache mechanisms that also need to be cleaned?

I understand that you can get your self in trouble independently of DataTables if references exist to DOM elements (or events exist) that are in the child rows, but lets assume this is not the issue for the moment.

This question has an accepted answers - jump to answer

Answers

  • allanallan Posts: 61,723Questions: 1Answers: 10,108 Site admin
    Answer ✓

    DataTables, when it hides a child row, doesn't remove it from memory - rather it will keep the row in memory so the same child row can be shown again. The show / hide is just that, it is showing or hiding a row that has already been preset (although often you set it at the same time as showing it).

    There isn't currently an API for destroying child rows. This is an oversight in the new API and I'll look at adding a suitable option for that in 1.10.1. Thanks for the suggestion!

    Allan

  • scottkmitch1scottkmitch1 Posts: 9Questions: 3Answers: 0

    Thanks for your quick response and adding support for this would be great. My current use case has the rows providing a preview of the content and then child rows which display the full content. These child rows are built by ajax requests which result in a large number of DOM elements (all with their own event handlers). This data changes and it doesn't make much sense to cache the content. For this use case I am leaking memory like a sieve and depending on your time table I may look into moving away from this approach. Is there a release cycle, road map, and/or features list for the 1.10.1 release? Do you have a feeling for how common this use case is?

  • allanallan Posts: 61,723Questions: 1Answers: 10,108 Site admin

    I'm planning on releasing 1.10.1 near the end of the month with this and a few other fixes. Many already committed, but there are still a couple I know I need to fix. I don't actually have a public issue tracker - well, there is github and you are welcome to open and issue for it there if you like, but I tend to use forum bookmarks and todo.txt as a tracker for myself, since its just me running the project.

    Regarding how common it is - using child rows is quite a common use case for DataTables. Normally the contents are very complex, but I have seen some with frames and all sorts of other things going on in them.

    I'll try to make this change at the start of next week when I'm back in the office and post back here when its is done.

    Allan

  • scottkmitch1scottkmitch1 Posts: 9Questions: 3Answers: 0
    edited May 2014

    I opened issue 325 and created the associated pull request 326. Hopefully this should get you started. I think it would be appropriate to discuss the detailed followup on github under this issue.

This discussion has been closed.