Execution of JS in IE6 Much Slower Than FireFox 3

Discussion in 'Javascript' started by Tom, Jan 15, 2009.

  1. Tom

    Tom Guest

    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.
    Tom, Jan 15, 2009
    #1
    1. Advertising

  2. Tom

    RobG Guest

    On Jan 16, 6:23 am, Tom <> 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
    RobG, Jan 16, 2009
    #2
    1. Advertising

  3. RobG wrote:
    > On Jan 16, 6:23 am, Tom <> 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.)
    The Natural Philosopher, Jan 16, 2009
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andre Charbonneau

    XPath queries getting slower and slower...

    Andre Charbonneau, Feb 15, 2005, in forum: Java
    Replies:
    0
    Views:
    536
    Andre Charbonneau
    Feb 15, 2005
  2. Mark
    Replies:
    20
    Views:
    1,624
    Dave O'Hearn
    Dec 27, 2004
  3. Replies:
    27
    Views:
    527
    Gabriel Genellina
    Jun 14, 2007
  4. dustbort
    Replies:
    3
    Views:
    3,855
    JosipJaic
    Jun 18, 2010
  5. Tim Meagher
    Replies:
    3
    Views:
    98
    Ray Costanzo [MVP]
    Oct 4, 2005
Loading...

Share This Page