Garbage collection after removing child nodes

[Tim Streater]

I have a <selectthat I build up dynamically. To later clear and
repopulate it, I can't use the standard trick of:

ptr_to_select.o ptions.length = 0;

because sometimes the <selectwill contain <optgroup>s. These stay in
the <select(for Firefox and IE7, not Safari), after setting the length
to zero.

What seems to work on all browsers is:

while (ptr_to_select. childNodes.leng th>0)
{
ptr_to_select.r emoveChild (popup.lastChil d);
}

but, are the removed children properly garbage collected? Especially as
some will be the <optgroup>s and have children themselves.

[Bart Van der Donck]

Re: Garbage collection after removing child nodes

Tim Streater wrote:

I have a <selectthat I build up dynamically. To later clear and
repopulate it, I can't use the standard trick of:
>
ptr_to_select.o ptions.length = 0;
>
because sometimes the <selectwill contain <optgroup>s. These stay in
the <select(for Firefox and IE7, not Safari), after setting the length
to zero.
>
What seems to work on all browsers is:
>
while  (ptr_to_select. childNodes.leng th>0)
     {
     ptr_to_select.r emoveChild (popup.lastChil d);
     }
>
but, are the removed children properly garbage collected? Especially as
some will be the <optgroup>s and have children themselves.

The only way to know is to test with heavy data, and then see how many
CPU is freed by the browser after the delete-action is finished.

--
Bart

[Thomas 'PointedEars' Lahn]

Re: Garbage collection after removing child nodes

Bart Van der Donck wrote:

>[...] are the removed children properly garbage collected? Especially as
>some will be the <optgroup>s and have children themselves.

>
The only way to know is to test with heavy data, and then see how many
CPU is freed by the browser after the delete-action is finished.

Memory (RAM), not CPU.


PointedEars