Firefox 3.5.5 crapping itself on large updates inside event handlers, just me?

Discussion in 'HTML' started by Nik Coughlin, Dec 14, 2009.

  1. Nik Coughlin

    Nik Coughlin Guest

    Adding 2000 elements to the page outside an event handler takes a handful of
    milliseconds. Doing the same from within an event handler takes over 6
    seconds. Doesn't happen in Chrome, Opera, Safari or even IE.

    Does anyone else see this with Firefox 3.5.5 or is it just something weird
    happening on my computer? I thought it might be some flaky addon, so tried
    it with a fresh Firefox profile, same result.

    Demo:
    http://nrkn.com/temp/ffwtf/
     
    Nik Coughlin, Dec 14, 2009
    #1
    1. Advertisements

  2. Nik Coughlin

    rf Guest

    Inside event handler: 257ms.

    Firefox 3.5.3.
     
    rf, Dec 14, 2009
    #2
    1. Advertisements

  3. Nik Coughlin

    dorayme Guest

    Inside, 360ms on my Safari, but on my FF latest Mac, 2892ms
     
    dorayme, Dec 14, 2009
    #3
  4. Nik Coughlin

    Neredbojias Guest

    Repeated testing gave me 58ms outside/130ms inside in ff 3.5.5 on my
    setup. In ie8 it was 0/0?? Opera 10.10 seems to be 16/16 and Safari
    4.0.4 for Windows 6/59. Last but not least, SeaMonkey 1.1.16 showed
    about 16/60-80. I dumped Chrome because its js runtime is bad.
     
    Neredbojias, Dec 14, 2009
    #4
  5. Nik Coughlin meinte:
    FF 3.5.5:
    107ms vs. 253ms.

    Chromium 4.0.270:
    9ms vs. 103ms.

    Opera: 10.10:
    18ms vs. 23ms.

    All on Ubuntu 9.10 64bit.


    Gregor
     
    Gregor Kofler, Dec 14, 2009
    #5
  6. Firefox 3.5.5 Debian 64bit linux 180/520 ms respectively.
     
    The Natural Philosopher, Dec 14, 2009
    #6
  7. "Outside event handler: 99ms
    Inside event handler: 11050ms"

    in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091123
    Iceweasel/3.5.5 (like Firefox/3.5.5; Debian-3.5.5-1) GTB5

    ("GTB" apparently means Google ToolBar but I have a lot of other add-ons
    installed, too.)

    But: Your analysis of the situation is wrong, and your test case is flawed.

    0. There is no "page". The test case uses an (invalid) HTML document.

    It must be considered invalid HTML because there is no public
    standard that specifies its current HTML-resembling markup.
    As a result, since there is not at least one implementation of it that
    implements each feature (which is an exit criterion for a W3C Working
    Draft to become a W3C Proposed Recommendation), it is more then likely
    that different implementations exhibit different behavior already just
    because of their different level of support for this non-standard markup.

    Consequently, for the time being, Web development test cases should be
    Valid HTML 4.01 (the newest Specification with Recommendation status)
    unless a specific markup language and its DOM is being tested.

    1. It is incorrect of you to say "inside event handler" and "outside event
    handler" for two reasons:

    1. The code in which you are using `innerHTML' is event _listener_-code.
    (The built-in unmutable event handler of the DOM implementation calls
    it.)

    2. Where you display "outside event handler" is actually *within*
    the event listener for the `load' event of the `body' element.

    2. `test' is particularly bad an identifier for a property of the global
    object, especially if there is an element with ID `test' in the test
    document.

    Remember that testing frameworks may introduce such a method that would
    be overwritten, and that IDs of elements become the names of properties
    of a host object in the scope chain in MSHTML/IE and potentially other
    runtime environments that support this referencing.

    3. You are missing here that non-standard implementations like that of
    MSHTML do not pass a reference to an event object to an event listener.

    As a result, for those environments you are displaying the wrong text
    (according to your wrong definition, though) because `e' is either `null'
    or (being `undefined' in my tests with MSIE 6.0 on Wine) converts to 0,
    the same as `null' does. (See the ECMAScript Language Specification,
    Edition 5, 11.9.3, steps 3, 8 and 9, and Edition 3 Final which
    corresponds more with the tested environment but says the same.)

    4. *Most important*: You are missing here that the initial situation for the
    second test is not the same as for the first test.

    Because in the first test the `div' element with ID `test' did not have
    any children before the assignment to `innerHTML', while in the second
    test it did have 2000 SPAN children each with one text node child that
    need to be removed first.

    That need for removal, potential marking for garbage collection or
    effective garbage collection of host objects no longer being referred to,
    and re-addition would explain the greater time it takes very well, much
    better than your (provably wrong) notion of "outside" and "inside".

    The differences between runtime environments that you observed could then
    be easily attributed to a more sophisticated comparison algorithm in the
    `innerHTML' setter (that would not remove and re-add if the content is
    the same), and garbage collection using other parameters, in at least
    one of these environments. As for the former, it would be worth to take
    a look at the source code of the respective implementation; as for the
    latter, it would be worth to take a look at the size of the memory
    footprint of the user agent before and after the test.

    Bottom line: Be sure what you are testing before complaining, and avoid the
    proprietary `innerHTML' property (as if that was news around here).


    F'up2 comp.lang.javascript;
    please do not crosspost to alt.* and Usenet without.

    PointedEars
     
    Thomas 'PointedEars' Lahn, Dec 14, 2009
    #7
  8. Nik Coughlin

    Roy A. Guest

    As Thomas 'PointedEars' Lahn says "your test case is flawed", but you
    have proven a point I allready know. Firefox, in many cases sucks. A
    bare bone browser like Firefox should be best in test cases like this.
    It can't compete with Google Chrome, but it should be better than any
    other browser. There is far to many web pages that is badly written,
    so the error handling in firefox should far be better than this.

    Even if your is "your test case is flawed", the numbers is correct.
    All is happening inside a javascript body, and the rest of the
    document is all ready fixed. Firefox is just not up to the task.
     
    Roy A., Dec 16, 2009
    #8
  9. Nik Coughlin

    Neredbojias Guest

    Bull. Ff may be slower than Chrome but Chrome is seriously flawed when
    it comes to javascript. Besides, the OP's lament is atypical and
    probably relates to something specific to his dilemma. And just how
    *should* ff (or any browser) handle errors in code or markup as well?
    I do agree that Mozilla should address the nagging, long-persistent
    parsing problems that still infest the browser and strive to make it
    load more quickly than it presently does rather than trying to
    incorporate new doodads which will ultimately only add to the problem.
    Nevertheless, ff is the best browser out there and has been for a long
    time.
     
    Neredbojias, Dec 16, 2009
    #9
  10. Nik Coughlin

    Roy A. Guest

    I agree.
    FF is not near the best browser out there. It is bare bone, and it
    stinks.
     
    Roy A., Dec 16, 2009
    #10
  11. Nik Coughlin

    Jorge Guest

    FF is an excellent browser. Safari, Chrome & Opera too. The one that
    stinks is IE... :)
     
    Jorge, Dec 16, 2009
    #11
  12. Nik Coughlin

    dorayme Guest

    Do you know what the expression "bare bones" means?
     
    dorayme, Dec 16, 2009
    #12
  13. Nik Coughlin

    Jorge Guest

    Minimum, limited, minimalist ?
     
    Jorge, Dec 16, 2009
    #13
  14. Nik Coughlin

    dorayme Guest


    Oh, a misunderstanding Jorge! I was just asking Roy, it was not meant to
    be a trivia quiz...
     
    dorayme, Dec 16, 2009
    #14
  15. Nik Coughlin

    Roy A. Guest

    Firefox is great if you need any of the many extensions. Some of these
    extensions, like NoScript, make the browser go bananas. When I tested
    NoScript the browser started to crash. I could not uninstall it or
    reinstall Firefox. I had to uninstall Firefox, delete all folders, and
    then install it again.

    IMO, Firefox without extensions should be as fast as any browser.
     
    Roy A., Dec 16, 2009
    #15
  16. Nik Coughlin

    Jorge Guest

    LOL. I know. But what's the point in asking him that ?
     
    Jorge, Dec 16, 2009
    #16
  17. Nik Coughlin

    dorayme Guest

    Do you think all cars should be equally fast? You some sort of universal
    conceptual communist or something? <g>
     
    dorayme, Dec 16, 2009
    #17
  18. Nik Coughlin

    Roy A. Guest

    A browser that has noting else to brag about should be fast.
    Conceptual communist? Is your world that black and white?

    Anyone that have used Firefox can see that it don't live up to its
    expectations.

    When you install it, it has nothing to offer, when you install ad-ons
    it seems ok.
     
    Roy A., Dec 16, 2009
    #18
  19. Nik Coughlin

    dorayme Guest

    But it has things to brag about. It was regarded by many of us as a
    great contrast to IE in keeping much more to the standards that are
    admired by the web developing world. It does not seem to me to be
    importantly slower than other browsers in surfing but I agree it is a
    real slow coach starting up, it maybe thinks it is the engines in the
    Titanic, maybe I don't know any more because I have it *for* its
    extensions and not that much else.

    I am afraid so, Roy, am big of B&W pics, both still and movie.
    Perhaps nowadays, it is not as competitive. But was once.
     
    dorayme, Dec 17, 2009
    #19
  20. FF 3.5.3
    Outside : 156MS
    Inside : 16 seconds (with a long period of "Not Responding").

    There is another similar bug with Firefox 3.5.3 and Textareas. If you
    set the value of a textarea to more than about 500 lines, you get a
    similar sort of very long delay. This is an already reported bug.
     
    Julian Turner, Dec 18, 2009
    #20
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.