Re: <select>.remove() Performance and Necessity



Hi Rob

RobG wrote:
You mean 3,000 option elements? Do you really want to do that?

I have only recently stumbled across the school of thought that says
JavaScript and HTML are more than capable of providing the functionality and
performance needed for a complete browser-based application GUI, so I
thought it was time that I educated myself a little bit about the potential
of these tools. To that end I've built a proof-of-concept example, one part
of which is the loading a database-query result-set into a scrolling list.
Now, I imagine 99% of the time we'd be talking 10s to low 100s of matching
rows, but I don't think 3000 is ridiculous or out of the realms of
possibility. (Especially as the user is empowered (by the hot abort button)
to terminate the query at any time, if they so choose. The "All transactions
between a certain date range" scenario.)

Adding 3,000 options takes Safari 750ms, Firefox 220ms and Opera
530ms.

Thanks for the example code and real figures. I know I should've done that.

Your code on my box takes 20910ms to add 3K and 4907ms to remove them :-(

The second and subsequent times the "add" consistently took ~5600ms and the
"remove" stayed at 4860ms.

Does anyone else have IE7 that they can run Rob's code on to check?

Ask MS to fix their browser.
: : : :
Ditch IE?

Certainly looks the way to go. What could it possibly be doing with all that
CPU? Bitmap or hash algorithm for *every* free byte in memory?

Ok, going forward, can I run FireFox on my Windows2000 box and have it
co-exists happily with IE? (IE in one window, FF in another?)

Cheers Richard Maher


.