Jump to content

Does removeChild still keep that node in memory?


rich
 Share

Recommended Posts

Does anyone know if when you removeChild() on a dom node it's still actually retained in memory? 
 
 
But I can't find mention of this requirement in the W3C spec, so wondered if modern browsers still actually do this or not? When you removeChild it returns the node, but if you discard it (or don't capture it) I'm wondering if the browser does actually still keep hold of that memory or not.
 
Basically I want to know if it's quite safe to create 1 new dom node for every sprite in my game, or if I should cache/pool them and recycle them instead - keeping in mind I need to target mobile, so I don't want to exhaust browser memory.
Link to comment
Share on other sites

removeChild() doesn't trigger any deleting but it removes a reference to that object from the parent. If there are no more references to the object elsewhere then the object should be cleaned up during normal Garbage Collection.

 

If you do removeChild() but still have references to the object it should stay in the dom. The menu system for my game Drugbound has lots of removeChilds (to make the object not visible) but still keeps the objects in the dom via other reference in my running game, therefore GC doesn't delete them from memory.

 

At least that's the behavior of the GC as I understand it.

Link to comment
Share on other sites

rIf you do removeChild() but still have references to the object it should stay in the dom.

Actually it just stays in memory, not in the DOM. It's like when you create your HTML elements in Javascript: they are stored in the memory, but do not belong to the document yet.

But as you said, for any object, as long as there is still a reference to it, it won't be deleted from the memory, just like in Java or ActionScript.

Link to comment
Share on other sites

I'm not worried about maintaining a reference to a deleted dom node, that's fine. I understand completely what removeChild should do if you maintain the node it returns.

 

What I was wondering was if, as the MDN documentation says, the browser will keep the node in memory regardless if a reference to it still exists anywhere or not, as that is exactly what the docs imply - they make no mention of gc running at all. May have to make some profiler tests to find out, but I expect it to be different across browser!

Link to comment
Share on other sites

It will get garbage collected if there are no references to it. I remember confirming this last year in Chrome, Firefox, Opera and IE8+

 

Just be mindful the this open bug for Chrome regarding memory leaks. If you see memory usage go through the roof, then it may be the bug... and not the fact that you adding/removing many DOM elements.

Hopefully they fix it soon - very annoying!

Link to comment
Share on other sites

The way it is written in the MDN documentation makes sense. If you maintain a reference to the oldChild with var, then it will persist in memory. The spec doesn't seem to specify what user agents should do here regarding memory. I would assume that is beyond the scope of the spec.

 

This is directly from MDN:

 

var oldChild = element.removeChild(child);element.removeChild(child);

 

  • child is the child node to be removed from the DOM.
  • element is the parent node of child.
  • oldChild holds a reference to the removed child node. oldChild === child.

The removed child node still exists in memory, but is no longer part of the DOM. You may reuse the removed node later in your code, via the oldChild object reference.

Link to comment
Share on other sites

Yeah I'm seeing what you mean re: the docs. Which basically means I need to run some tests on which is faster: Adding and Removing elements and NOT retaining the node for re-use, or pooling them. I suspect it will be a case of 50/50 depending on the browser you test with  :mellow:

Link to comment
Share on other sites

Sounds like a http://jsperf.com/ candidate.

It's probably hard to reliably bake into jsperf. Basically what is interesting is how consistent and fast the rendering performance is. I'm almost sure that the pooled nodes will win.

The main question seems to be how to pool them. Just leave them in the DOM, display:none them (removes them from the render tree, probably a good idea), or to completely detach and reatach them (might also be a good idea especially if you do all the manipulations on the nodes first an then reattach them). Now I think by far the best way to evaluate them is in an actual game (like) program. It's very easy to get very wrong results with synthetic benchmarks (texture sharing, overdraw, object creation/destruction .rates, other things that already tax the GC/rendering, etc) and then look at the actuall frame rate with a keen eye on if/how often it drops. 

 

Cheers,

Jonas

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...