Jump to content


Photo
- - - - -

Does removeChild still keep that node in memory?

dom

  • Please log in to reply
11 replies to this topic

#1 rich

rich

    Administrator

  • Administrators
  • 3787 posts
  • twitter:photonstorm
  • LocationUK

Posted 06 March 2013 - 10:25 AM

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.mo...ode.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.

phaser-header.png

 

phaser docshttp://www.photonstorm.com | "Quality is a great business plan. Period." - John Lasseter, Pixar


#2 @99golems

@99golems

    Advanced Member

  • Members
  • PipPipPip
  • 156 posts
  • twitter:@mrlasertron

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.


Play my latest HTML5 desktop browser game, The Sword By My Side, now! (for the band The Thermals)

swordbymyside_title.png

http://twitter.com/99golems

http://slouchcou.ch


#3 @99golems

@99golems

    Advanced Member

  • Members
  • PipPipPip
  • 156 posts
  • twitter:@mrlasertron

Posted 06 March 2013 - 03:22 PM

*said something dumb so i'm retracting it*


Play my latest HTML5 desktop browser game, The Sword By My Side, now! (for the band The Thermals)

swordbymyside_title.png

http://twitter.com/99golems

http://slouchcou.ch


#4 remvst

remvst

    Advanced Member

  • Members
  • PipPipPip
  • 322 posts
  • twitter:remvst
  • LocationAmiens, France

Posted 06 March 2013 - 03:54 PM

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.


banner-440x70.png


#5 rich

rich

    Administrator

  • Administrators
  • 3787 posts
  • twitter:photonstorm
  • LocationUK

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!


phaser-header.png

 

phaser docshttp://www.photonstorm.com | "Quality is a great business plan. Period." - John Lasseter, Pixar


#6 EmployeeNumber8

EmployeeNumber8

    Member

  • Members
  • PipPip
  • 29 posts

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!



#7 rich

rich

    Administrator

  • Administrators
  • 3787 posts
  • twitter:photonstorm
  • LocationUK

Posted 06 March 2013 - 04:28 PM

Someone ought to fix the MDN documentation then :)


phaser-header.png

 

phaser docshttp://www.photonstorm.com | "Quality is a great business plan. Period." - John Lasseter, Pixar


#8 EmployeeNumber8

EmployeeNumber8

    Member

  • Members
  • PipPip
  • 29 posts

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.



#9 @99golems

@99golems

    Advanced Member

  • Members
  • PipPipPip
  • 156 posts
  • twitter:@mrlasertron

Posted 06 March 2013 - 05:31 PM

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


Play my latest HTML5 desktop browser game, The Sword By My Side, now! (for the band The Thermals)

swordbymyside_title.png

http://twitter.com/99golems

http://slouchcou.ch


#10 rich

rich

    Administrator

  • Administrators
  • 3787 posts
  • twitter:photonstorm
  • LocationUK

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  :mellow:


phaser-header.png

 

phaser docshttp://www.photonstorm.com | "Quality is a great business plan. Period." - John Lasseter, Pixar


#11 andrewjbaker

andrewjbaker

    Newbie

  • Members
  • Pip
  • 9 posts
  • LocationNottinghamshire, UK

Posted 07 March 2013 - 10:05 PM

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


#bbg (HTML5 browser-based games) IRC channel on Freenode


#12 Jonas Wagner

Jonas Wagner

    Newbie

  • Members
  • Pip
  • 1 posts
  • twitter:29a_ch

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. 

 

Cheers,

Jonas







Also tagged with one or more of these keywords: dom

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users