Closed Bug 613931 Opened 14 years ago Closed 11 years ago

brizzly.com unusably slow with Firefox 4

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: levon, Unassigned)

References

Details

(Keywords: perf, regression) 

Running Firefox 4.0 Beta 7 (and earlier betas), the Twitter page of brizzly.com
is unusably slow. Firefox 3.5 series is usable.

I think you might have to create an account to observe it, but it's very noticable once you have.
Why do you think that the problem is in the JS Engine ?
>Firefox 3.5 series is usable.
and Firefox 3.6 ?

Is it faster in the Firefox safemode ?
>Running Firefox 4.0 Beta 7 (and earlier betas)
all betas ?
Which build had the problem first ?

What are the steps to reproduce ?
Firefox 3.6 series is OK too (Fedora 13).

JS Engine was just a guess - I really have no idea.

-safe-mode is not faster: for example, I also see this on twitter.com
If I load a user's timeline, sometimes pressing page down will take around
15 seconds. During that time, the X pointer is grabbed (or appears so) so I
can't switch away from Firefox.

I'm not sure which beta build broken, but I think I remember that beta2 was OK.

I know this isn't very helpful, but it's going to be difficult for me to collect further info given it happens sporadically, and I can't do anything at all when it's happening.
b8 is equally broken. In a comparison, Chrome is very fast, Firefox 3 OK, and Firefox 4 almost literally unusable.
blocking2.0: --- → ?
Keywords: qawanted
What X drivers and server version do you have?  And does disabling hardware acceleration help? (Preferences -> Advanced -> General)
Assignee: general → nobody
Component: JavaScript Engine → Graphics
Keywords: perf, regression
QA Contact: general → thebes
I registered and added Twitter and viewed it -- seems quite snappy to me using my http://hg.mozilla.org/tracemonkey optimized build, changeset 714d7e569fcd.

/be
John, there's no URL set for this bug and no Steps To Reproduce. Can you supply some so I can confirm I'm testing correctly. Also, could you try a recent build, via http://nightly.mozilla.org/ or better?

/be
I suspect it's Linux-specific, and that you're not testing on 64-bit Linux like John.
Mike, comment 4:

[root@pent ipv4]# rpm -q xorg-x11-server-Xorg
xorg-x11-server-Xorg-1.8.2-4.fc13.x86_64
[root@pent ipv4]# rpm -q xorg-x11-drv-nvidia-173xx
xorg-x11-drv-nvidia-173xx-173.14.27-1.fc13.x86_64

Disabling h/w acceleration didn't help, still the multi-second drop-outs with a grabbed X cursor.

comment 5 / comment 6:

Brendan, I suspect you'd need quite a lot of stuff in your timeline for it to show up anyway. Unfortunately I haven't yet found a site that exhibits the same behaviour without having to set something up and log in so "URL" isn't appropriate. I can't really use FF4 day to day to find it either.

I'm trying the latest nightly and will report back.
Tried both:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011/01/2011-01-11-03-mozilla-central/firefox-4.0b10pre.en-US.linux-x86_64.tar.bz2

and

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011-01-11-03-tracemonkey/firefox-4.0b9pre.en-US.linux-x86_64.tar.bz2

Both still had the problem, especially with Brizzly, although the latter seemed generally faster if that makes sense. Tried both with and without h/w accel enabled.
I just tried to create a new Twitter account. As soon as I clicked on "Create" I saw a 40-second drop out before the captcha appeared.
Can someone reproduce this and profile? John, during these "drop outs", is your CPU pegged, & if so, with what process?
Have to ask: any add-ons? Firebug disabled?

/be
comment 11: the CPU is pegged. I ran top -b and reproduced, Xorg is 100% on a CPU.
Profile of Xorg hopefully coming soon.

comment 12: reproducible in -safe-mode
The initial profile wasn't much use unfortunately:

CPU: Intel Core/i7, speed 1200 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000
samples  %        image name               app name                 symbol name
9958     35.9404  nvidia_drv.so            nvidia_drv.so            /usr/lib64/xorg/modules/drivers/nvidia_drv.so
3865     13.9495  libpixman-1.so.0.18.0.#prelink#.PF9qex (deleted) libpixman-1.so.0.18.0.#prelink#.PF9qex (deleted) /usr/lib64/libpixman-1.so.0.18.0.#prelink#.PF9qex (deleted)
3632     13.1086  vmlinux                  vmlinux                  mwait_idle_with_hints
1836      6.6265  libxul.so                libxul.so                /usr/local/firefox-4.0b10pre/libxul.so
528       1.9057  vmlinux                  vmlinux                  hpet_next_event
519       1.8732  Xorg (deleted)           Xorg (deleted)           /usr/bin/Xorg (deleted)
366       1.3210  [vdso] (tgid:1724 range:0x7fff483ff000-0x7fff48400000) Xorg (deleted)           [vdso] (tgid:1724 range:0x7fff483ff000-0x7fff48400000)
361       1.3029  libc-2.12.1.so (deleted) libc-2.12.1.so (deleted) /lib64/libc-2.12.1.so (deleted)
285       1.0286  libwfb.so                libwfb.so                wfbSolid

I've updated so a couple of the binaries are old. After I reboot / relogin next, I'll try again and see if it's more useful.
xrestop at the time looks uninteresting:

20 - John Levon - Mozilla Firefox ( PID:16078 ):
        res_base      : ox6200000
        res_mask      : ox1fffff
        windows       : 41
        GCs           : 102
        fonts         : 1
        pixmaps       : 68
        pictures      : 102
        glyphsets     : 112
        colormaps     : 0
        passive grabs : 0
        cursors       : 6
        unknowns      : 22
        pixmap bytes  : 73606
        other bytes   : ~10264
        total bytes   : ~83870
OK. This is starting to feel a little like a driver bug that Firefox is exposing.

Finding a regression window can help a lot with fixing the problem: https://wiki.mozilla.org/QA/Triage#How_to_Help_with_Regressions_--_Finding_Regression_Windows

John, do you think you could look into getting that regression window?
Yes, I can spend some time binary chopping. I'll start with the earlier 4.0 betas.
For now, we'll say this doesn't block, but I'm willing to reconsider once we have a regression window.
blocking2.0: ? → -
Sorry to say that this *does* happen with beta2. If somebody can tell me the rough date range of the nightlies (and ftp dir I guess) between the working 3.6.13 and the 4.0 betas I can start going back through those :/
John, 3.6 branched from trunk back in August 13, 2009.

4.0 beta 2 is around July 7, 2010.

You should be able to get nightlies at ftp://ftp.mozilla.org/pub/firefox/nightly/ in the 2009/ and 2010/ directories, and by month within those.  You want the mozilla-central nightlies.

Thanks for doing this!
Thanks Boris. My method was this: place Facebook, Brizzly, and Twitter in tabs, and quit the browser so they appear on load (I needed to 'Restore' often as well). This made it very reproducible: the cursor would be grabbed for a long time at some point during the load/restore of the browser. Binary searching I found that:

ftp://ftp.mozilla.org/pub/firefox/nightly/2010/07/2010-07-15-03-mozilla-central/firefox-4.0b2pre.en-US.linux-x86_64.tar.bz2 is OK

ftp://ftp.mozilla.org/pub/firefox/nightly/2010/07/2010-07-16-03-mozilla-central/firefox-4.0b2pre.en-US.linux-x86_64.tar.bz2 is BROKEN

I verified these results somewhat: beta1 was in fact OK, beta2 is broken, various builds post-July-16th are all broken, etc.

Let me know the next steps (I can be on IRC if that helps).
John, what are the hg.mozilla.org urls for those builds in about:buildconfig?
Sorry, buildconfig was new to me:

OK, 2010-07-15-03: http://hg.mozilla.org/mozilla-central/rev/5fda39cd703c

BROKEN, 2010-07-16-03: http://hg.mozilla.org/mozilla-central/rev/96de199027d7
Thanks.  That would be this range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5fda39cd703c&tochange=96de199027d7

Which is when retained layers landed....  Chances are, that's what regressed this.
Is there anything I can do to further triage of this issue?
John, I don't think so.  Unless Robert thinks it would be useful to bisect using try builds...
Blocks: 564991
(In reply to comment #2)
> During that time, the X pointer is grabbed (or appears so) so I
> can't switch away from Firefox.

Do you mean the cursor is stationary on the screen, or that clicking over other apps has no effect?

If the former, then the pointer is probably not grabbed.  More likely the (single-thread) X server is busy processing graphics (maybe trying to composite with pixman on the CPU while one of the surfaces is in VRAM).

It may be interesting to experimently configure the X driver with 'Option "RenderAccel" "off"' to see whether that provides a (unfortunate) workaround.

Another thing to try might be running firefox with MOZ_X_SYNC=1 in the environment and randomly attaching gdb (possibly from a remote connection) to get backtraces to indicate which call might be the slow one, but to be useful this needs a firefox build with symbols, and I don't think we have those available for download.
comment 27: I meant the latter. There is no way to switch away from Firefox, interact with the WM etc. Exactly as if an XGrabPointer() is in effect.

I can try the RenderAccel thing, presuming the nvidia driver understands it.
(In reply to comment #28)
> comment 27: I meant the latter. There is no way to switch away from Firefox,
> interact with the WM etc. Exactly as if an XGrabPointer() is in effect.

Thanks.  Do other apps continue to draw while the mouse is ineffective?
e.g. does a terminal continue to update with top -d 1 running?
Other apps continue to update, though often slowly since the CPU is pegged (apparently the other 3 CPUs don't seem to help much!)
Still present with RC1 (and several Linux kernel / nvidia updates since). I suppose it's possible I'm the only one who will see this, but it seems unlikely.
Still there with the official release :/
QA Contact: thebes → bjacob
Is this bug still reproducible? I'm on linux x86-64, ubuntu 11.10, radeon driver, firefox 12, and it's fast for me.
Yup, goes unresponsive with Twitter open for seconds at a time, Firefox 9.0.
This is no longer reproducible on a up to date build, latest Nightly 25.0a1 (buildID: 20130722030226). Removing qawanted from keywords and changing the status of the bug to WFM. If anyone can reproduce the issue please add qawanted back to keywords and reopen the bug.
Status: NEW → RESOLVED
Closed: 11 years ago
Keywords: qawanted
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.