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
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.
Version: unspecified → Trunk
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/ ?
Component: General → General
Product: Firefox → Core
QA Contact: general → general
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)
One thing worth checking... does setting the "accessibility.win32.force_disabled" preference to "true" change the Windows behavior?
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).
Depends on: 610391
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.
In other words, unless we want to mutate this bug to cover the "3s, not 1s" issue, it should probably be resolved worksforme...
(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.
> 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.
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.