Does removeChild still keep that node in memory?

[rich]

Does anyone know if when you removeChild() on a dom node it's still actually retained in memory? 

 

According to the MDN docs it is https://developer.mozilla.org/en-US/docs/DOM/Node.removeChild

 

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.

[@99golems]

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.

[@99golems]

*said something dumb so i'm retracting it*

[remvst]

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.

[rich]

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!

[EmployeeNumber8]

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!

[rich]

Someone ought to fix the MDN documentation then

[EmployeeNumber8]

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.

[@99golems]

yes i was confused for a sec between dom and memory. my mistake. But i'm in agreement with employeenumber8.

[rich]

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 

[andrewjbaker]

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

[Jonas Wagner]

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