605128 - Very slow page rendering with lots of textfields: 3 minutes vs. less than 1 s in other browsers

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Jürgen Kreileder]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6) Gecko/20100101 Firefox/4.0b6
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6) Gecko/20100101 Firefox/4.0b6

The attached test page takes about 3 minutes to render in Firefox (safe-mode, so without any add-on).  The whole system (Windows 7, 4-core i7 860, NVidia GTS 240) is very sluggish during that time.  Especially screen updates are very slow.

The same page takes less than 1 second to render in Google Chrome 7 and Internet Explorer 8.


Reproducible: Always

Comment 1

[Jürgen Kreileder]

Attachment: test page

Comment 2

[Jürgen Kreileder]

On my MacBook Pro (dual-core i7) the page loads in about 20 seconds (4.0b8pre).  This is a lot faster than on the Windows machine (which has more CPU power) but still at least 20 times slower than Chrome on Windows/OS X.

Comment 3

[Nickolay_Ponomarev]

On Vista this page loads in ~10 seconds on Firefox nightly (Mozilla/5.0 (Windows NT 6.0; rv:2.0b8pre) Gecko/20101106 Firefox/4.0b8pre), ~3 seconds in Chrome.

Could you retest using http://nightly.mozilla.org/ ?

Comment 4

[Jürgen Kreileder]

It's 7 seconds for me on OS X now with the current nightly.  I'll test with Windows 7 on Monday.

(One thing I noticed with b6 on Windows: Turning off hw accelerated rendering made the page load in 1 minute instead of 3.  And XP was noticeably faster than Win 7 too: about 20 seconds for the test page on a slower machine)

Comment 5

[Boris Zbarsky [:bzbarsky]]

One thing worth checking... does setting the "accessibility.win32.force_disabled" preference to "true" change the Windows behavior?

Comment 6

[Jürgen Kreileder]

accessibility.win32.force_disabled=true brings it down to 5 seconds on Windows 7 with b6.

The current nightly also needs only 5 seconds (even with accessibility.win32.force_disabled=false).

Comment 7

[Boris Zbarsky [:bzbarsky]]

I see.  So you're running with accessibility enabled for some reason (tablet device?  Kaspersky antivirus?  Some other MSAA thing?).  The a11y team fixed a bunch of performance stuff since 3.6, which explains why the nightly is ok either way.

For the rest, I just profiled the pageload and well over half the time is due to the <select>s, not the textfields; specifically due to bug 610391.

If I ignore that, then the remaining time breaks down as:

  14% creating scrollbar stuff for the selects (roc, did we ever file a bug on
      nixing that gunk?).
   5% creating the anonymous content and its frames for the combobox (the
      display area and dropdown arrow).
   2% frame state restoration.
  10% other frame construction stufff (including textfields, etc).
  24% layout (at least half of this is comboboxes).
  24% the pre-onload layout flush that webkit skips to make its onload numbers
      look better (bug 581685).
  10% parsing.
   5% painting
   3% Mac event loop gunk

In any case, it sounds like the "many minutes" issue was just the really slow accessibility stuff in 3.6.

Comment 8

[Boris Zbarsky [:bzbarsky]]

In other words, unless we want to mutate this bug to cover the "3s, not 1s" issue, it should probably be resolved worksforme...

Comment 9

[Jürgen Kreileder]

(In reply to comment #7)
> I see.  So you're running with accessibility enabled for some reason (tablet
> device?  Kaspersky antivirus?  Some other MSAA thing?). 

No, it's a normal workstation with Trend Micro OfficeScan.  As far as I can tell accessibility is turned off. 

The only thing that definitely is enabled is switching between keyboard layouts (us+german).


Apart from that I agree with closing this as WFM.

Comment 10

[Boris Zbarsky [:bzbarsky]]

> As far as I can tell accessibility is turned off. 

Well... not if that pref affects things.  ;)

In any case, a11y running is no longer a perf disaster, so I suppose we shouldn't worry about it too much.

Comment 11

[(no longer active)]

I tested the effect of my patch in bug 610391 on the test case here.  We basically load the test case with very little noticeable delay, and we're a lot faster than Chrome now.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Sounds fixed.