«

I have a <select> that 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 <select> will 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.

Tim Streater wrote:

> I have a <select> that 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 <select> will 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

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