Closed Bug 712883 Opened 13 years ago Closed 12 years ago

Extreme difference in page performance between Chrome/Firefox when typing text in Facebook

Categories

(Core :: Layout: Block and Inline, defect)

Product:
Core
Component:
Layout: Block and Inline
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox9 --- affected
firefox10 --- affected
firefox11 --- affected
firefox12 --- affected
status1.9.2 --- ?

People

(Reporter: djst, Unassigned)

References

(
URL
)

Details

(Keywords: perf, qawanted, top100, Whiteboard: [see comment 13 for analysis][Snappy])

Attachments

(1 file, 1 obsolete file)

Flicker clip
880.56 KB, video/x-ms-wmv
Details 
(This might be a dupe but I at least made an effort to try to find similar bugs, but couldn't find any. This also reminds me of bug 606461 for Twitter.)

There is a pretty serious performance issue in Firefox when using Facebook since (I think?) they switched to the new Timeline interface. Specifically, typing in text boxes is dog-slow and sometimes even hangs Firefox to the point of it saying "Not responding" in the title bar. 

See screencasts:
* Firefox http://screencast.com/t/ydUfqRtxlN
* Chrome http://screencast.com/t/W6F53hp9Qgp

Tested in Firefox 9 and Aurora 10.0a2 (2011-12-20) using a completely new profile with no other tabs open or extensions installed; and Chrome 16.0.912.63 m.
I believe Timothy has looked into this sort of thing before.... it's more likely to be painting than JS.
I don't know how much painting is involved in just echoing a character in a text box, but it's of course possible. 

If it's painting, that would also explain why almost everything on Facebook is slower in Firefox (including scrolling, switching to the tab from another tab, etc).
> I don't know how much painting is involved in just echoing a character in a text box

The bug would generally be if we paint too much... ;)
Can you post a regression window?
Juan, can someone from QA help us track down a regression window? Given the magnitude of the regression and the popularity of the site, figuring this out should be a priority.
Keywords: qawanted
I've been trying both 8.0.1 and 9.0.1 on a Win7 VM with new profiles, a testing facebook account with not much going on on it, and I have not been able to reproduce the problem yet. I'll ask other people to try with richer accounts and report back.
I've since tried on the nightly and back in 9.0.1 and I can see the issue. I don't know why I can see it very clearly in 9.0.1 when earlier I wasn't able to. I'll send out email to the team to get a regression range.
My facebook interface does not look like the Timeline interface that David shows in the screenshot. How do I enable that interface?
I'm running the latest Nightly on Windows 7 32-bit and I'm not seeing this

Mozilla/5.0 (Windows NT 6.1; rv:12.0a1) Gecko/20111222 Firefox/12.0a1
(In reply to Marcia Knous [:marcia] from comment #8)
> My facebook interface does not look like the Timeline interface that David
> shows in the screenshot. How do I enable that interface?

Try this link: https://www.facebook.com/about/timeline

Nightly x64 on Win7 does only seem to hang minimally; but not only on Facebook, but also here on Bugzilla. Since I use a large memory cache and no disk cache this could relate to garbage collection in my case. Coincidently CPU usage raises for a small amount whenever a hang occurs.
I'm not convinced this is a regression in Firefox itself, but more of a recent exposure of where we're significantly slower than Chrome on certain paint/JS heavy sites. I've seen relative slowness in Firefox/Aurora/Nightly compared to Chrome for a long time here, and I've always been able to reproduce that with new profiles. It's just that I've never seen this dramatic different before.

Upon further testing, this behavior is observed in 3.6.x (latest) too. I've also tried with different Facebook accounts, so I can confirm that it's not e.g. tied to the number of friends or what activities you have on Facebook or anything like that.

I can also confirm that this happens in *all* text boxes, not just those in the new Timeline interface. 

Additional analysis: it appears that JS code is executed every time you type a letter in a text box. The primary feature is the friends name auto-complete that pops up a list of matching names when you begin typing something like "Davi" (for David Tenser). I didn't observe any difference in functionality of the site between Chrome and Firefox, so this is likely not the case of bug 606461, where different JS code was executed in Gecko compared to Chromium. 

Juan, I'm surprised you don't experience the slowness -- are you guys using too fast computers? I will give this a try on my wife's computer to make sure this isn't a local issue with my machine.
OK, this is more machine-dependent than I thought -- it turns out that this is noticeable only if I select the "Balanced" performance plan on my Sony Vaio Z VPCZ2190X and running on battery. I'll admit I don't know fully what these plans are doing, but if I switch to "High performance" I hardly notice a difference between Firefox and Chrome anymore.

Fwiw, my machine has a Mobile Intel HD Graphics chipset and the CPU is i7-2620M @ 2.70 GHz, 8 GB RAM, SSD hard drive (raid-0). I'm guessing that the most relevant pieces here is what the performance plans does to the graphics performance -- it's clear that it's not just typing in text boxes in Facebook that becomes slower with "Balanced", as even switching between tabs is dog-slow. So, bz is probably right that this might be related to painting as well (though JS code is also noticeably slower).

Crucially, Chrome performs flawlessly regardless of power plan chosen! It's always wicked-fast, though scrolling on Facebook is noticeably jerkier even in Chrome when using "Balanced" on battery. So, both browsers are affected, but Firefox so much more so.

QA: if you can, please switch to power saving plans and try this on various hardware. Using the right configurations, it should be very easy to notice the performance differences between the browsers.
What happens in short is that we invalidate almost the entire page after each key press. On Windows this problem is magnified in that we force a paint after every key press, so if the user types two (or more) letters while we are still painting the results from the last keystroke we will paint twice (or more), once for each key press, instead of just painting the result after both key presses. Bug 627628 covers not doing this anymore. It is blocked on part 24 of bug 598482 (or something which solves the same problem) landing. So we should be able to land this soon.

Invalidating way too much is because of what I'm calling "the float invalidation bug". The code at http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsBlockFrame.cpp#2538 invalidates the entire line if we reflow anything inside an inline line. Where this bites us frequently in practice is if we reflow something inside a float then we invalidate the entire line the float is on (so at minimum the entire contents of the float). The textbox is inside a float, but more importantly Facebook changes the DOM on key presses inside the float near the textbox to handle the autocomplete like David mentions, and this is what causes us to need to reflow inside the float. The plan for fixing that and many more problems with invalidation is bug 539356. This is further away.

I haven't profiled, but I don't think the JS engine is taking much time here.
Interesting -- thanks for the insights.

Fwiw, I have now tested this on another machine (~3 years old Packard Bell running Windows Vista, new Firefox/Aurora/Nightly profiles) and on this slow computer the difference between Chrome and Firefox is noticeable even with power plugged in, but switching to battery and the "Energy saving" battery mode, the difference is even more pronounced. If I type fast enough by just frantically hitting keys, the whole window occasionally locks up with the "(Not responding)" title bar in Firefox... never in Chrome.

So just in case anyone ever suspected it, this bug is not limited to my machine. Based in Timothy's comment above, I would assume this is reproducible on just about any not-wicked-fast PC running e.g. Windows Vista/7 on battery.

(As a side-note, I can also confirm that other graphics-intensive operations such as switching back to the Facebook tab after browsing around on other tabs is *very* slow -- sometimes over 2 seconds -- on both machines using the energy saving battery modes, and they're always instantaneous in Chrome. It seems very related, but for the record, I filed another bug about tab switching lags in the past: bug 694859.)
I can confirm that in a MacBook Air running 10.7.2 this issue is present in Firefox 9 but not in Firefox 8.0. Also, in Firefox 3.6 there's some lag between keystrokes and the characters actually showing up in the box, but the issue about the line breaks doesn't appear in 3.6 as far as I can see.
Comment 7 and comment 15 confuse me, because I can reproduce this in *any* Firefox version. I'm currently testing this in 7.0.1 and get the same extreme lags when typing in Facebook (even showing the "(Not responding)" window title message occasionally). 

Switching battery plan to "High performance" effectively eliminates these lags. Again, make sure you test this with energy conserving battery plans and actually running on battery. I don't know to what extent this is possible on the Mac, and if Mac hardware in general handles this better, so for best results, use a PC.
Attached file Flicker clip (obsolete) — 
The character painting delay is reproducible on the following environments (with Facebook timeline enabled, writing in the status textbox):
*Windows 7 x86_32bit:
Mozilla/5.0 (Windows NT 6.1; rv:12.0a1) Gecko/20111222 Firefox/12.0a1
Mozilla/5.0 (Windows NT 6.1; rv:11.0a2) Gecko/20111222 Firefox/11.0a2
Mozilla/5.0 (Windows NT 6.1; rv:10.0a2) Gecko/20111220 Firefox/10.0a2
Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20100101 Firefox/10.0 beta 1
Mozilla/5.0 (Windows NT 6.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20100101 Firefox/9.0
Mozilla/5.0 (Windows NT 6.1; rv:8.0.1) Gecko/20100101 Firefox/8.0.1
Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0
Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.25) Gecko/20111212 Firefox/3.6.25

Besides the delay, when typing quickly, there is also a flicker happening on Win7 on Fx 4->12. (please see attached video. The first flicker, when Fx window turned black, happend only once, when video was recorded. The second flicker, when a new tab appears in the windows task bar for a short period of time, appears every time).
On 3.6.25 I could reproduce the flicker only if I clicked on the textbox while characters were painted after I stopped writing.
On all builds, after the flicker, all remaining characters are painted.
If you type more text than the default box size allows, textbox does not automatically adjust its size an typed text is not viewable until characters are finished painting


*Mac OSX 10.6.8:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0a1) Gecko/20111222 Firefox/12.0a1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0a2) Gecko/20111222 Firefox/11.0a2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20100101 Firefox/10.0 beta 1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0.1) Gecko/20100101 Firefox/8.0.1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20100101 Firefox/5.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.25) Gecko/20111212 Firefox/3.6.25

On all builds, the delay in painting the characters was observed when typing quickly. No fllicker observed


*Ubuntu 11.10, x86_64; GeForce 8400 GS/PCI/SSE2 -- 3.3.0 NVIDIA 280.13
Mozilla/5.0 (X11; Linux x86_64; rv:12.0a1) Gecko/20111221 Firefox/12.0a1
Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0 beta 1
Mozilla/5.0 (X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Mozilla/5.0 (X11; Linux x86_64; rv:5.0.1) Gecko/20100101 Firefox/5.0.1 

Issue is reproducible with a clean profile, but only when madly typing random characters at a high speed (the experience is a bit sluggish-there is a slight delay when passing to a new line in the text box). The experience is normal here if I type in a normal manner (no difference towards google-chrome); I can't see a significant difference between the Firefox versions mentioned above on Linux.
I've attempted this on different text boxes in facebook. I could only constantly reproduce while using timeline and typing in the Status text box. I've checked with other text boxes (search, comments at friend, posts on walls) but I couldn't replicate.


*Windows XP:
Mozilla/5.0 (Windows NT 5.1; rv:12.0a1) Gecko/20111222 Firefox/12.0a1
Mozilla/5.0 (Windows NT 5.1; rv:11.0a2) Gecko/20111222 Firefox/11.0a2
Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20100101 Firefox/10.0 beta 1
Mozilla/5.0 (Windows NT 5.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Mozilla/5.0 (Windows NT 5.1; rv:8.0.1) Gecko/20100101 Firefox/8.0.1
Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Mozilla/5.0 (Windows NT 5.1; rv:5.0.1) Gecko/20100101 Firefox/5.0.1
Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.25) Gecko/20111212 Firefox/3.6.25
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16

The paint issue is reproducible, but the flicker issue not.
Attached video Flicker clip — 

        Attachment #584041 -
        Attachment is obsolete: true

    
    

    
  
The "flicker issue" as Mihaela describes it is what I mean in comment 16 when the title quickly changes to "(Not responsible)". It is definitely also reproducible in different versions of Firefox, since it's related to how Windows handles application windows that stops responding -- Windows then changes the title text and overlays that text regardless of how Firefox normally paints its window borders. This all happens because Firefox is so busy processing that it locks up all its CPU resources.
Depends on: 627628, dlbi
Assignee: general → nobody
URL: http://www.facebook.com/
Component: JavaScript Engine → Layout: Block and Inline
Keywords: perf, 
          
            top100
QA Contact: general → layout.block-and-inline
Whiteboard: [see comment 13 for analysis]

          status1.9.2:
          --- → ?

          status-firefox10:
          --- → affected

          status-firefox11:
          --- → affected

          status-firefox12:
          --- → affected

          status-firefox9:
          --- → affected
OS: Windows 7 → All
Hardware: x86_64 → All
Version: 12 Branch → Trunk

    
    

    
  
Timothy, did you look at why exactly the Facebook page is so slow to repaint the page, beyond just the invalid area being overly large?

    
    

    
  
If there's a small fix that can limit the damage here, we should do it. Bug 539356 will take too long and be too risky for branches.

    
    

    
  
The [snappy] keyword should be associated with this bug as it impacts perceived performance.
Whiteboard: [see comment 13 for analysis] → [see comment 13 for analysis][Snappy]

    
    

    
  
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #20)
> Timothy, did you look at why exactly the Facebook page is so slow to repaint
> the page, beyond just the invalid area being overly large?

It doesn't seem to be anything specific. Just a moderately complex webpage. It has images, border-radius with overflow hidden, and some box-shadow, but nothing really out of the ordinary that sucks a lot of cycles.

The fact that David's laptop has such a difference between balanced and performance mode is weird though.

    
    

    
  
(In reply to Timothy Nikkel (:tn) from comment #23)
> The fact that David's laptop has such a difference between balanced and
> performance mode is weird though.

Is it?  If we're getting paint events every N ms and each takes N-1 ms then all you see is high CPU usage, but if each takes N+1 ms they start piling up and we lose.

    
    

    
  
(In reply to Timothy Nikkel (:tn) from comment #23) 
> The fact that David's laptop has such a difference between balanced and
> performance mode is weird though.

To reiterate, I am able to reproduce this on a 3+ year old PC laptop running Vista regardless of power mode. So, it seems that my high end Vaio is just becoming more like an old computer when in "balanced" mode on battery. 

My guess: Just try this on an old computer and you should be able to reproduce it fairly easily.

    
    

    
  
David also reports that switching to a Facebook tab takes seconds when in balanced mode in another bug is what makes me wonder what is causing that.

    
    

    
  
Is there a Facebook page that reproduces this problem that doesn't require a Facebook account?

    
    

    
  
I don't think so. You need to log in to get a textbook to type in.

    
    

    
  
Hmm. So how do I work on this bug if I don't want join Facebook?

    
    

    
  
Create a fake testing account?

    
    

    
  
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #31)
> Isn't that against the rules?

We have test accounts. Marcia can hook you up I'm sure.

    
    

    
  
I know that this is regarding Facebook but the same situation happens in Youtube.

I am merely looking for something that we can disable so we stop seeing that same situation. My hardware is weak and nowhere near an i7, but that has never happened before, even while playing 720p videos. Now, it's haywire and Safe Mode sometimes doesn't prevent the lag, so far it sometimes works okay on Safe Mode in Pale Moon.

Real-world experience is here. (I am megamanx there)
https://support.mozilla.org/en-US/questions/909274?s=typing+in+youtube+is+laggy&r=0&e=sph&as=s

    
    

    
  
Youtube does suffer from basically the same problem ("the float invalidation bug"), but there is a simple change they can make to their page to avoid the problem. The updating of the number of characters remaining is what triggers the problematic invalidate. If instead of a span, Youtube used a textbox the problem would go away.

    
    

    
  
(In reply to Timothy Nikkel (:tn) from comment #35)
> Youtube does suffer from basically the same problem ("the float invalidation
> bug"), but there is a simple change they can make to their page to avoid the
> problem. The updating of the number of characters remaining is what triggers
> the problematic invalidate. If instead of a span, Youtube used a textbox the
> problem would go away.

Thanks for the information, I was blaming Flash and it didn't seem like it was the problem entirely.

Float invalidation lost me, so what's to blame, Java or HTML5?

I am merely here for a temp fix, something to disable? (Annoying to have to go use another browser to comment on videos, I comment on many daily, so that's why I am complaining)

I am surprised that Opera doesn't suffer lag, Dragon and CoolNovo have a slight lag but extremely minor.

    
    

    
  
May i know how's the status of this bug?

    
    

    
  
I didn't amend, I always use High Performance and still came across that, I hardly comment with the Fox to know anymore. If a possible solution is posted on the Nightly, I'll use Nightly from here on.

Indeed, my CPU is low-end:
AMD Athlon X2 Dual-Core QL-64 2.1Ghz

Still, are there any temporary solutions, I can't second-guess what needs to be enabled/disabled to stop the re-occurrence.

    
    

    
  
If the modifications that Facebook did to the DOM on every key press to support autocomplete of friends names were done inside of a display: none subtree then the reflows that cause the invalidations of most of the page wouldn't happen.

    
    

    
  
Just to be clear, this isn't specific to the profile page with timeline, right?

    
    

    
  
No, just the timeline view takes longer to paint so it is more visible there.

    
    

    
  
(In reply to Timothy Nikkel (:tn) from comment #41)
> No, just the timeline view takes longer to paint so it is more visible there.
Thanks.  I'm working on getting this routed to the right place at Facebook.

    
    

    
  
Tim Yung, one of our engineers at Facebook did some research, and this is what he came up with:
This is due to a flaw in the way Firefox invalidates the page (in order to decide what needs repainting). If the subtree of a floated DOM node is manipulated, the entire floated container (and nodes that depend on the floated container such as other floated containers) is invalidated and required repainting.

Unfortunately, the entire two-column layout on Timeline depends on floating. The reason that each keypress triggers a repaint is because in order to implement the mentions input.

The mentions input needs to update the contents of a hidden "highlighter" container on every keypress to keep the "highlighter" in sync with the contents of the textarea. This "highlighter" is responsible for 1) highlighting tagged entities as well as 2) positioning the "— with X." that comes after the textarea in the composer.

    
    

    
  
Yes, that all matches my understanding. Is it possible to make the "highlighter" display:none when it is hidden? That should avoid the bug in Firefox where we invalidate way too much because of floats.

    
    

    
  
Yup, we will hide the "highlighter" when possible to help mitigate the float invalidation issue. However, we have to make it visible as soon as any tagged phrases are highlighted or if "— with X." trails afterward. In those cases, excessive invalidation will continue occur until float invalidation is fixed.

    
    

    
  
Yes, you are right, but it's an improvement. We can brainstorm other approaches.

Is it possible to make the DOM of the highlighter not be a descendant of the large floated element and still position it where you need it to be?

    
    

    
  
Unfortunately not without some pretty messy hacks. The component used to render the taggable inputs is used not only in the top left of Timeline, but all inputs you can tag people (including any of the stories on Timeline where you can comment).

Any idea how far we are from fixing the float invalidation bug?

    
    

    
  
(In reply to Timothy Yung from comment #47)
> Unfortunately not without some pretty messy hacks. The component used to
> render the taggable inputs is used not only in the top left of Timeline, but
> all inputs you can tag people (including any of the stories on Timeline
> where you can comment).

You could use the same approach to position it for each one.

> Any idea how far we are from fixing the float invalidation bug?

I'm not sure as I'm not the one working on the fix, but probably far enough away that a work around would be desirable.

    
    

    
  
This should be resolved now on the Facebook end of things.  Can someone verify it?

    
    

    
  
(In reply to Shawn Wilsher :sdwilsh from comment #49)
> This should be resolved now on the Facebook end of things.  Can someone
> verify it?

It sure seems fixed on my end, yes. That's very nice! 

(In reply to Timothy Nikkel (:tn) from comment #26)
> David also reports that switching to a Facebook tab takes seconds when in
> balanced mode in another bug is what makes me wonder what is causing that.

Yes, bug 694859 definitely still happens on this machine. But this particular Facebook issue is gone now that Facebook itself worked around our perf issues. Someone else should resolve this bug though, because I'm not sure what the resolution is on our end since the underlying issue is still there.

    
    

    
  
Easy enough for me to do :)

Thanks David!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME

    
    

    
  
What is the word on the Youtube fix?

    
    

    
  
Okay, I assume no one wants to work on the Youtube problem.

If someone ever does, I would like to be informed, please.
The Userscript temp solution does not make up for fact that users will still have this problem(maybe spread the word), it should really be a fix within the browser.

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: