Execution of JS in IE6 Much Slower Than FireFox 3

[Tom]

I got such great help on my last post I'm trying again with another
problem. I've built a web app that dynamically creates, via Perl
cgi's + Oracle db, web pages with a form and lots of fields (text,
select, checkboxes, etc), and many hidden fields. There are a number
of js functions that evaluates user inputs, does arithmetic, sets the
color in table cells, and other stuff. In FireFox 3 the js is
executed in a blink of the eye. In IE 6 it seems to take forever.
Let's say in FireFox the elapsed time is < 0.5 second. In IE6 the
elapsed time varies from 5-8 seconds. The js function performs
numerous typeof test, gets data from hidden fields as as well as user
input fields, uses parseFloat, lots of "if(Goodness == "I") type
tests, nothing terribly exotic. My question is why does IE6 perform
so much slower than FF ? The amount of data that gets streamed back
to the browser is approximately equivalent to a 4 MB htm file. As the
amount of data that streams back to the browser is reduced the js
performance in IE improves. Is there some setting in IE that will
improve the performance ? I've been supporting this web app for
several years now and have always tested in FF and IE during
development of new capability. This is the first time I've
encountered such a discrepancy in performance. Any suggestions or
ideas ? Thanks.

 

[RobG]

I got such great help on my last post I'm trying again with another
problem.  I've built a web app that dynamically creates, via Perl
cgi's + Oracle db,  web pages with a form and lots of fields (text,
select, checkboxes, etc), and many hidden fields.  There are a number
of js functions that evaluates user inputs, does arithmetic, sets the
color in table cells, and other stuff.  In FireFox 3 the js is
executed in a blink of the eye.  In IE 6 it seems to take forever.

There are two basic parts to javascript in a browser: code that deals
with native and built-in components, and those that deal with the
DOM. The native stuff tends to be pretty quick in all browsers, some
of the string stuff in IE is really fast, some really slow.

As for the W3C DOM, IE 6 performance is dismal. At the time it was
developed, MS were more interested in their proprietary extensions.
Compatibility with the W3C DOM seemes to have been grudgingly added so
they could say IE was "standards compliant", more or less.

IE 7 and 8 seem to be going down the standards route more seriously,
which is great to see. IE's standards compliance is getting better
and there seems to be some attention being given to performance, but
it still lags well behind other modern browsers.

In your particular case, you might try some basic profiling of the
code to find the slowest bits, then post minimal examples here.
Likely there are other ways to do it that are faster in IE (or perhaps
not) but without seeing the code, only general comments can be
provided.

 

[The Natural Philosopher]

There are two basic parts to javascript in a browser: code that deals
with native and built-in components, and those that deal with the
DOM. The native stuff tends to be pretty quick in all browsers, some
of the string stuff in IE is really fast, some really slow.

As for the W3C DOM, IE 6 performance is dismal. At the time it was
developed, MS were more interested in their proprietary extensions.
Compatibility with the W3C DOM seemes to have been grudgingly added so
they could say IE was "standards compliant", more or less.

IE 7 and 8 seem to be going down the standards route more seriously,
which is great to see. IE's standards compliance is getting better
and there seems to be some attention being given to performance, but
it still lags well behind other modern browsers.

In your particular case, you might try some basic profiling of the
code to find the slowest bits, then post minimal examples here.
Likely there are other ways to do it that are faster in IE (or perhaps
not) but without seeing the code, only general comments can be
provided.

This explanation gybes with my experience also. Yea even unto IE7.

I managed to improve things by caching the location of DOM elements of
interest by dynamically building arrays of them. The first pass isn't
sweet, but as more and more got cached, performance improved no end.

Somewhere I read that the hashing algorithms used are completely
different, making e.g. a getElementsByTag etc very slow on IE, if there
are a lot of them.

Also use IDs exclusively if you can. Don't search on names.


And do you HAVE to use hidden inputs? You could perhaps use un-displayed
DIVS with ids. to hold server generated variables.

Star by generating a test page with loads of ID'ed elements
and loads of hidden input ones and comparing speed to select from either.

So.
1/. establish what elements the browser can find the fastest.
2/. consider developing an array of pointers to them, that is a faster
search than the elements themselves. You can do that on load, or
dynamically as needed.
4/. Only use hidden variables when you need to POST data back, and
intercept the submit routine, and preload them only when needed.

(I generally effectivley disable the submit anyway, as i use lots of
submit type buttons that set various variables to control server side
action. Hitting 'return' may submit, but without setting the 'update'
variable. nothing happens except a page reload.)