957173 - Firefox hangs on big sites like GitHub

Status: RESOLVED INCOMPLETE

(Core :: Layout, defect)

Description

[sjw]

Firefox has trouble to render big sites. On my hardware, it hangs immediately and I have to kill its process.

Comment 1

[Josh Matthews [:jdm]]

What operating system? What version of Firefox? Does anything change if you run in safe mode (https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode)?

Comment 2

[sjw]

I've tested on Ubuntu 13.10 and Win7 with latest Nightly 64bit on a clean profil.

Comment 3

[Boris Zbarsky [:bzbarsky]]

I profiled this, and it mostly seems to be script the page is running when XHRs finish, if you mean the multi-second freeze on pageload and then the periodic freezes as you scroll.

I see freezes of about the same length in Safari, for what it's worth.

Comment 4

[sjw]

It hangs for minutes (5=<) and every time you try to click, scroll or any other activation it hangs again. Even if you work on an other window or tab.
Other browsers loads the site quite faster and won't become unstable.

Comment 5

[Boris Zbarsky [:bzbarsky]]

I can't reproduce the "minutes" thing at all...

Comment 6

[Paul Silaghi, QA [:pauly]]

(In reply to Boris Zbarsky [:bz] from comment #3)
> the periodic freezes as you scroll.
I see freezes without scrolling, with the focus on other tabs.
29.0a1(2014-01-09), win 7 x64

Comment 7

[Ashickur Rahman]

I check the link, it takes some time to render but don't freezes on Nightly 29, Linux X86_64.
[bugday-20140113]

Comment 8

[sjw]

There is may be a performance relation between these bugs.

Comment 9

[Paul Rouget [:paul]]

(In reply to sjw from comment #8)
> There is may be a performance relation between these bugs.

Are the devtools involved? If the console is not used, it's not related.

Comment 10

[sjw]

(In reply to Paul Rouget [:paul] from comment #9)
> Are the devtools involved? If the console is not used, it's not related.

Nope.

Comment 11

[Bhavik Chauhan]

I tried it on win7 64bit and found it was freezing at regularly. not only while scrolling but while using other tabs as wll

Comment 12

[David Weir (satdav)]

I can conform ths bug as github is doing it with me too 

I have tried Firefox 28.0 on windows with a clean profile and safe mode its doing it for me

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

Maybe a reduced test case would help. 
I'm not sure how to narrow this down in order to put it into an appropriate product and component. 

We could take a look to see if this is a regression.

Comment 14

[Alice0775 White]

Stack on hang
bp-464c8f89-3b8b-420d-bdd9-5d72b2140603
bp-8f0127ec-0cf0-43ee-8b4c-e2cf72140603

Comment 15

[Boris Zbarsky [:bzbarsky]]

Those are both empty stacks.  :(

Comment 16

[Ben Kelly [:bkelly, not reviewing]]

I wonder if the length of the pauses is dependent on memory resources available.

If I do the following:

1) Open github URL in second tab
2) Scroll until I get some pauses (just a few seconds each on my developer machine)
3) Return to the tab for this bug

Then I continue to see pauses even while scrolling the bug page.  (Which agrees with comment 11.)

Looking at my resource monitor I can see memory usage fluctuating up and down every few seconds.  There is jank at the peaks, so I assume thats GC/CC kicking in.

If I just idle on the bug tab with github open in the second tab I still see memory usage fluctuating with jank when it peaks.

How powerful is your machine?  Perhaps you are getting stuck in very long GC/CC cycles due to extreme memory pressure.

Is this page continuously creating objects which have to be collected?

Comment 17

[sjw]

GitHub implemented a workaround for this bug. "Sorry, we had to truncate this directory to 1,000 files."
But the problem itself is not fixed.

This week I was testing the new e10s feature (bug 516752) and if you enable it, you will see a huge improvement.

Comment 19

[sjw]

Take URL from bug 741196, which seems to be a dupe of this.

Note this:
(In reply to Emil Obermayr from comment #0)
> I can not check back, but I would say this got much worse since updating
> from 10 to 11

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Seems unlikely we're going to find a useful regression range on this bug at this point. Are we even sure that the fileformat case is even the same root cause as the original Github one? I'm pretty sure there are other bugs on file for large tables causing Fx performance issues (vs. the discussion in this bug pointing to a legit script performance issue with the original Github URL).

I'm thinking we should re-profile the fileformat URL now attached to this bug and go from there.

Comment 21

[Boris Zbarsky [:bzbarsky]]

> Are we even sure that the fileformat case is even the same root cause as the original
> Github one?

No.  Whoever dupped one performance bug on one url to another on another url... shouldn't do that.

I'm going to resolve this incomplete, since there's not much that can be done here at this point, and reopen bug 741196.

Comment 22

[Melroy]

Also. What is not was Boris told you yet. Press the 'vote' link, next to 'importance', on that bug report #741196. That will increase priority.