Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Execution of JS in IE6 Much Slower Than FireFox 3

Reply
Thread Tools

Execution of JS in IE6 Much Slower Than FireFox 3

 
 
Tom
Guest
Posts: n/a
 
      01-15-2009
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.
 
Reply With Quote
 
 
 
 
RobG
Guest
Posts: n/a
 
      01-16-2009
On Jan 16, 6:23*am, Tom <(E-Mail Removed)> wrote:
> 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.


--
Rob
 
Reply With Quote
 
 
 
 
The Natural Philosopher
Guest
Posts: n/a
 
      01-16-2009
RobG wrote:
> On Jan 16, 6:23 am, Tom <(E-Mail Removed)> wrote:
>> 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.
>
>
> --
> Rob


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.)




 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: HELP! Ping getting slower and slower and slower! Paul Computer Information 2 04-03-2012 05:58 PM
ADO.NET query execution much slower than SQL Management Studio dustbort ASP .Net 3 06-18-2010 12:59 PM
Google groups (Beta version) is much slower than original usenet69@hotmail.com Firefox 4 02-09-2005 04:21 PM
HD-DVD growth will be much slower than DVD's was RichA DVD Video 38 12-24-2004 11:22 PM
Why is MS Networking so much slower on XP than 98? Jerry Rivers Computer Support 5 12-31-2003 05:10 PM



Advertisments