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.options.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.length>0)
{
ptr_to_select.removeChild (popup.lastChild);
}

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

[Bart Van der Donck]

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.options.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.length>0)
* * *{
* * *ptr_to_select.removeChild (popup.lastChild);
* * *}

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]

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