1312645 - Regression in site render time during boot on Firefox 49

Status: UNCONFIRMED

(Core :: Layout, defect)

Description

[Dave Meyers]

Attachment: Firefox 49 - Render Time Regression.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36



Actual results:

With the release of Firefox 49, we've noticed an increase of ~300ms in the time it takes to render the page for Outlook.com/Outlook Web App during boot/startup (this is purely the time it takes to render the DOM and doesn't include script downloads or other network requests). The first screenshot attached shows the increase in render time just for Firefox in the AppCache and NoCache boot scenarios. The second screenshot shows our total page load time on Firefox broken down by version 48 and 49 as well as the change in sample sizes for each version. Based on the trends we're seeing (where times substantially increase around 9/23 at the same time as v49 becomes the predominant version) we think this might be related to the latest Firefox release.

Comment 1

[Andrew Overholt [:overholt]]

Maybe related to layout?

Comment 2

[Sylvestre Ledru [:Sylvestre]]

[Tracking Requested - why for this release]:
Important performance regression, we should investigate before 49 goes live.

Comment 3

[Sylvestre Ledru [:Sylvestre]]

Of course, s/49/50/ in comment #2

Comment 4

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

[Tracking Requested - why for this release]: It may be too late to do this in 50 assuming the fix is external given the platform-rel flag on it. Let's plan to address this in 51.

Comment 5

[Gerry Chang [:gchang]]

Track 51+ as important performance regression.

Comment 6

[Gerry Chang [:gchang]]

Hi Astley,
Can you help shed some light here or find an owner for this?

Comment 7

[Astley Chen (inactive)]

By using gecko profiler to collect more info, it seems pretty hard to have stable result on same test scenario. If we want to break down which parts contribute this 300ms slow down on Firefox 49, we probably require a static site/test case so that it could be a lot easier to narrow down the regression window and push further for more clarification.

Dave, is it possible ? or is there any other way to give same test condition ?

Comment 8

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

A test case would be helpful - this likely isn't going to be fixed for 51, though. 
I'm assuming 52/53 are also affected but am not certain.

Comment 9

[Milan Sreckovic [:milan] (needinfo for best results)]

And if we can measure it quickly enough, getting a mozregression to narrow down when this started showing up would be great.
Can somebody refresh my memory - when did we change the compiler version on Windows?  Because it may have been around 49, though it would be unfortunate if we traced the regression to that change.

Comment 10

[Andrew Overholt [:overholt]]

(In reply to Milan Sreckovic [:milan] from comment #9)
> Can somebody refresh my memory - when did we change the compiler version on
> Windows?  Because it may have been around 49, though it would be unfortunate
> if we traced the regression to that change.

Bug 1186064 indicates 50 so thankfully uncorrelated :)

We really need a profile here. Dave, can you capture one in Firefox? Go to https://new.cleopatra.io/ and follow the instructions.

Comment 11

[Jet Villegas (inactive)]

I'll look into getting a profile for this one.

Comment 12

[David Bolter [:davidb] (NeedInfo me for attention)]

I've emailed the reporter.

Comment 13

[Julien Cristau [:jcristau]]

Looks like this is stalled on getting a profile, marking wontfix for 52.

Comment 14

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

This is months old and I don't think we need to track it anymore. If we get a profile or another report of this happening in recent versions then maybe the bug will be actionable.