Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #27687 > unrolled thread

Is it necessary to explicitly destroy elements?

Back to article view | Back to comp.lang.javascript

Contents

  Is it necessary to explicitly destroy elements? "Leonardo Azpurua" <leonardo@exmvps.org> - 2015-05-16 11:14 -0430
    Re: Is it necessary to explicitly destroy elements? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-05-16 17:44 +0200
      Re: Is it necessary to explicitly destroy elements? "Leonardo Azpurua" <leonardo@exmvps.org> - 2015-05-16 11:32 -0430
        Re: Is it necessary to explicitly destroy elements? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-05-16 18:06 +0200
    Re: Is it necessary to explicitly destroy elements? "Leonardo Azpurua" <leonardo@exmvps.org> - 2015-05-16 11:42 -0430
      Re: Is it necessary to explicitly destroy elements? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-05-16 18:12 +0200
    Re: Is it necessary to explicitly destroy elements? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-05-16 18:09 +0200
      Re: Is it necessary to explicitly destroy elements? Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2015-05-16 22:05 -0300
        Re: Is it necessary to explicitly destroy elements? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-05-17 08:01 +0200
          Re: Is it necessary to explicitly destroy elements? Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2015-05-17 13:29 -0300
            Re: Is it necessary to explicitly destroy elements? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-05-17 19:06 +0200
        Re: Is it necessary to explicitly destroy elements? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-17 11:53 +0200
          Re: Is it necessary to explicitly destroy elements? Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2015-05-17 13:20 -0300

#27687 — Is it necessary to explicitly destroy elements?

Hi,

I have the idea of migrating a large Windows desktop application to the Web.

The browser will be used as a sort of Windows desktop, on top of wich 
several "forms" (HTML divs) will be opened and closed.

So far, I have managed to create a DIV, populating it with controls defined 
in a JSON object and attach events to these controls. Results are quite 
elementary yet, but the basic ideas seem to be pointing in the right 
direction.

As things grow, several DIVs will be opened, used, closed and disposed. So 
far, my "disposal" is limited to removing the top container element (i.e. 
the "form" DIV) from the document (document.removeChild(xDiv)).

My question (which is browser dependent, but there's no better place to ask 
browser related questions than here) is: do most "modern" browsers (say 
FireFox, Chrome, IE9+, Opera, Safari) automatically handle all the cleanup 
of a disposed element (detaching event handlers, freeing graphical 
resources, deallocating memory, etc) for all the elemets inside a disposed 
control, or is it necessary to provide a function to handle all of it 
explicitly?

Regards!

[toc] | [next] | [standalone]

#27688

Leonardo Azpurua wrote:

> My question (which is browser dependent, but there's no better place to
> ask browser related questions than here) is: do most "modern" browsers
> (say FireFox, Chrome, IE9+, Opera, Safari) automatically handle all the
> cleanup of a disposed element (detaching event handlers, freeing graphical
> resources, deallocating memory, etc) for all the elemets inside a disposed
> control, or is it necessary to provide a function to handle all of it
> explicitly?

Yes.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#27690

"Thomas 'PointedEars' Lahn" <PointedEars@web.de> escribió en el mensaje 
news:1445670.lN8oQKCnmD@PointedEars.de...
> Leonardo Azpurua wrote:
>
>> My question (which is browser dependent, but there's no better place to
>> ask browser related questions than here) is: do most "modern" browsers
>> (say FireFox, Chrome, IE9+, Opera, Safari) automatically handle all the
>> cleanup of a disposed element (detaching event handlers, freeing 
>> graphical
>> resources, deallocating memory, etc) for all the elemets inside a 
>> disposed
>> control, or is it necessary to provide a function to handle all of it
>> explicitly?
>
> Yes.


:-)

Ok... my wrong!

Yes, what?
Yes, they do properly handle all the disposal process?
Or yes, I must provide a proper disposal function?


Thanks!

[toc] | [prev] | [next] | [standalone]

#27692

Leonardo Azpurua wrote:

> "Thomas 'PointedEars' Lahn" <PointedEars@web.de> escribi� en el mensaje
> news:1445670.lN8oQKCnmD@PointedEars.de...
>> Leonardo Azpurua wrote:
>>> […] do most "modern" browsers (say FireFox, Chrome, IE9+, Opera, Safari) 
>>> automatically handle all the cleanup of a disposed element (detaching 
>>> event handlers, freeing graphical resources, deallocating memory, etc) 
>>> for all the elemets inside a disposed control, or is it necessary to 
>>> provide a function to handle all of it explicitly?
>> Yes.
> 
> :-)
> 
> Ok... my wrong!

I think the correct colloquial expression is “my _bad_”.

> Yes, what?
> Yes, they do properly handle all the disposal process?
> Or yes, I must provide a proper disposal function?

AFAIK none of the listed browsers experience memory leaks if you leave the 
clean-up to them.  As that is a feature of the layout engine, this applies 
to all browsers using the same layout engine, and should apply to all that 
are using a layout engine that is based on one of the former’s.

A statement regarding “most (modern) browsers” is untrustworthy.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#27693

"Stefan Ram" <ram@zedat.fu-berlin.de> escribió en el mensaje 
news:GC-20150516175759@ram.dialup.fu-berlin.de...
> "Leonardo Azpurua" <leonardo@exmvps.org> writes:
>>My question (which is browser dependent, but there's no better place to 
>>ask
>>browser related questions than here) is: do most "modern" browsers (say
>>FireFox, Chrome, IE9+, Opera, Safari) automatically handle all the cleanup
>>of a disposed element (detaching event handlers, freeing graphical
>>resources, deallocating memory, etc) for all the elemets inside a disposed
>>control, or is it necessary to provide a function to handle all of it
>>explicitly?
>
>  The garbage collectors should take care of JavaScript objects and of
>  DOM objects. But some collectors cannot clean up in all situations.
>  To be on the safe side:
>
> - avoid circular references between JavaScript objects and DOM objects
> - avoid using closure variables in event handlers
> - avoid using inline event handlers (onclick='f()')
> - avoid using expando properties
> - nullify expando properties and DOM references when not needed anymore

Nice!

Thanks!

[toc] | [prev] | [next] | [standalone]

#27695

Leonardo Azpurua wrote:

> "Stefan Ram" […]
>> "Leonardo Azpurua" <leonardo@exmvps.org> writes:
>>> […] do most "modern" browsers (say FireFox, Chrome, IE9+, Opera, Safari)
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> automatically handle all the cleanup of a disposed element (detaching 
>>> event handlers, freeing graphical resources, deallocating memory, etc) 
>>> for all the elemets inside a disposed control, or is it necessary to 
>>> provide a function to handle all of it explicitly?
>>
>>  The garbage collectors should take care of JavaScript objects and of
>>  DOM objects. But some collectors cannot clean up in all situations.
>>  To be on the safe side:
>>
>> - avoid circular references between JavaScript objects and DOM objects
>> - avoid using closure variables in event handlers
>> - avoid using inline event handlers (onclick='f()')
>> - avoid using expando properties
>> - nullify expando properties and DOM references when not needed anymore
> 
> Nice!

And wrong.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#27694

Stefan Ram wrote:

> "Leonardo Azpurua" <leonardo@exmvps.org> writes:
>>My question (which is browser dependent, but there's no better place to
>>ask browser related questions than here) is: do most "modern" browsers
>>(say FireFox, Chrome, IE9+, Opera, Safari) automatically handle all the
>>cleanup of a disposed element (detaching event handlers, freeing graphical
>>resources, deallocating memory, etc) for all the elemets inside a disposed
>>control, or is it necessary to provide a function to handle all of it
>>explicitly?
> 
>   The garbage collectors should take care of JavaScript objects and of
>   DOM objects. But some collectors cannot clean up in all situations.
>   To be on the safe side:
> 
> - avoid circular references between JavaScript objects and DOM objects
> - avoid using closure variables in event handlers
> - avoid using inline event handlers (onclick='f()')
> - avoid using expando properties
> - nullify expando properties and DOM references when not needed anymore

The IE memory leak issue has been resolved as of IE 9, so given the target 
environments none of this is necessary anymore.  Therefore, the programming 
language to which these measures applied, was JScript, not JavaScript, and 
only the MSHTML DOM, not all DOMs.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#27705

Thomas 'PointedEars' Lahn wrote:
> Stefan Ram wrote:
>
>> "Leonardo Azpurua" <leonardo@exmvps.org> writes:
>>> My question (which is browser dependent, but there's no better place to
>>> ask browser related questions than here) is: do most "modern" browsers
>>> (say FireFox, Chrome, IE9+, Opera, Safari) automatically handle all the
>>> cleanup of a disposed element (detaching event handlers, freeing graphical
>>> resources, deallocating memory, etc) for all the elemets inside a disposed
>>> control, or is it necessary to provide a function to handle all of it
>>> explicitly?
>>
>>    The garbage collectors should take care of JavaScript objects and of
>>    DOM objects. But some collectors cannot clean up in all situations.
>>    To be on the safe side:
>>
>> - avoid circular references between JavaScript objects and DOM objects
>> - avoid using closure variables in event handlers
>> - avoid using inline event handlers (onclick='f()')
>> - avoid using expando properties
>> - nullify expando properties and DOM references when not needed anymore
>
> The IE memory leak issue has been resolved as of IE 9, so given the target
> environments none of this is necessary anymore.  Therefore, the programming
> language to which these measures applied, was JScript, not JavaScript, and
> only the MSHTML DOM, not all DOMs.
>

Even though newer versions of modern browsers seem to have solved the 
memory leak problems of yore, this issue may arise again because of the 
single-page applications, for one, JS animations without properly 
clearing timers. So, we have one more reason to use CSS animations 
instead of JS animations.

In Chrome Developer tools, we can use the Timeline panel -> Memory view, 
and the 'Take Heap Snapshot' in Profiles, to take heap snapshots at a 
series of intervals.

According to Google [1], "the unique ability of the new tool is to 
reflect bidirectional dependencies between browser native objects (DOM 
nodes, CSS rules) and JavaScript objects. This helps to discover 
otherwise invisible leaks happening due to forgotten detached DOM 
subtrees floating around."

[1] <https://developer.chrome.com/devtools/docs/heap-profiling>

There is a good article by Addy Osmani teaching how to chase leaks with 
Chrome DevTools [2].

[2] 
<http://addyosmani.com/blog/taming-the-unicorn-easing-javascript-memory-profiling-in-devtools/>

-- 
Joao Rodrigues

[toc] | [prev] | [next] | [standalone]

#27706

Joao Rodrigues wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Stefan Ram wrote:
>>> - avoid circular references between JavaScript objects and DOM objects
>>> - avoid using closure variables in event handlers
>>> - avoid using inline event handlers (onclick='f()')
>>> - avoid using expando properties
>>> - nullify expando properties and DOM references when not needed anymore
>>
>> The IE memory leak issue has been resolved as of IE 9, so given the
>> target environments none of this is necessary anymore.  Therefore, the
>> programming language to which these measures applied, was JScript, not
>> JavaScript, and only the MSHTML DOM, not all DOMs.
> 
> Even though newer versions of modern browsers seem to have solved the
> memory leak problems of yore, this issue may arise again because of the
> single-page applications, for one, JS animations without properly
> clearing timers.

That is a separate issue.  Yes, one should clear one?s timers.

> So, we have one more reason to use CSS animations instead of JS 
> animations.

True, but /non sequitur/.
 
> There is a good article by Addy Osmani teaching how to chase leaks with
> Chrome DevTools [2].
> 
> [2]
> <http://addyosmani.com/blog/taming-the-unicorn-easing-javascript-memory-> profiling-in-devtools/>

Your research is lacking depth.

This article was published on 2013-04-11, around the time that Chrome 26 was 
released, which used WebKit as layout engine.  The current stable Chrome 
version is 42 and uses a different layout engine, Blink.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#27720

On 17/05/2015 03:01, Thomas 'PointedEars' Lahn wrote:
> Joao Rodrigues wrote:

>> There is a good article by Addy Osmani teaching how to chase leaks with
>> Chrome DevTools [2].
>>
>> [2]
>> <http://addyosmani.com/blog/taming-the-unicorn-easing-javascript-memory-> profiling-in-devtools/>
>
> Your research is lacking depth.
>
> This article was published on 2013-04-11, around the time that Chrome 26 was
> released, which used WebKit as layout engine.  The current stable Chrome
> version is 42 and uses a different layout engine, Blink.
>

I tested the new tools in my Chrome Version 42.0.2311.152 yesterday. So 
Addy's article still applies to the current stable version.

Anyway, thanks for the observations.

-- 
Joao Rodrigues

[toc] | [prev] | [next] | [standalone]

#27721

Joao Rodrigues wrote:

> On 17/05/2015 03:01, Thomas 'PointedEars' Lahn wrote:
>> Joao Rodrigues wrote:
>>> There is a good article by Addy Osmani teaching how to chase leaks with
>>> Chrome DevTools [2].
>>>
>>> [2]
>>> <http://addyosmani.com/blog/taming-the-unicorn-easing-javascript-memory->>>
>>> profiling-in-devtools/>
>> Your research is lacking depth.
>>
>> This article was published on 2013-04-11, around the time that Chrome 26
>> was released, which used WebKit as layout engine.  The current stable 
>> Chrome version is 42 and uses a different layout engine, Blink.
> 
> I tested the new tools in my Chrome Version 42.0.2311.152 yesterday. So
> Addy's article still applies to the current stable version.

It applies in the way that the tools are still available, although arranged 
differently.

Whether it applies in the way that there still is the possibility for such 
memory leaks is questionable.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#27710

Joao Rodrigues <groups_jr-1@yahoo.com.br> wrote on 17 mei 2015 in 
comp.lang.javascript:

> .. This helps to discover otherwise invisible leaks happening 
> due to forgotten detached DOM subtrees floating around."

I rather like the idea of such long-forgotten floats of branches 
["subtrees"] quietly going down the stream and now-and-then cleverly 
escaping the rocks in the Zambezian leakey rapids of the great garbage-
collector in the sky.

Perhaps the explorer in all of us wants to stand there with his monocular 
spyglass, saying, while pointing at the falls: "Livingstone, I presume".

Goggles and alike would want their tinted spyglasses to be binocular, all in 
the name of progress, but don't we all want to be the nobel primitive?

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#27719

On 17/05/2015 06:53, Evertjan. wrote:
> Joao Rodrigues <groups_jr-1@yahoo.com.br> wrote on 17 mei 2015 in
> comp.lang.javascript:
>
>> .. This helps to discover otherwise invisible leaks happening
>> due to forgotten detached DOM subtrees floating around."
>
> I rather like the idea of such long-forgotten floats of branches
> ["subtrees"] quietly going down the stream and now-and-then cleverly
> escaping the rocks in the Zambezian leakey rapids of the great garbage-
> collector in the sky.
>
> Perhaps the explorer in all of us wants to stand there with his monocular
> spyglass, saying, while pointing at the falls: "Livingstone, I presume".
>
> Goggles and alike would want their tinted spyglasses to be binocular, all in
> the name of progress, but don't we all want to be the nobel primitive?
>

LOL :-D

-- 
Joao Rodrigues

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web