Does removeChild still keep that node in memory?dom
Posted 06 March 2013 - 10:25 AM
Posted 06 March 2013 - 03:15 PM
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.
Posted 06 March 2013 - 03:54 PM
rIf you do removeChild() but still have references to the object it should stay in the dom.
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.
Looking for an internship :-°
Posted 06 March 2013 - 04:03 PM
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!
Posted 06 March 2013 - 04:09 PM
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!
Posted 06 March 2013 - 05:23 PM
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.
Posted 06 March 2013 - 06:38 PM
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
Posted 09 March 2013 - 12:55 PM
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.
Also tagged with one or more of these keywords: dom
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users