Facebook group navigation start: group first item is displayed

NEW
Unassigned

Status

()

Core
JavaScript Engine
a year ago
20 days ago

People

(Reporter: Alin Rus, Unassigned, NeedInfo)

Tracking

(Depends on: 2 bugs)

55 Branch
x86_64
Windows 10
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [perf-tools], URL)

(Reporter)

Description

a year ago
Name: Firefox
Version: 55.0a1
Windows 10 64 bit
buildID: 20170508030204

Steps to reproduce:
1. Launch browser.
2. Fill Facebook.com in Navigation Start, then press enter.
3. Login with credentials.
4. Record with Gecko Profile:
   Tap on a facebook group, and wait to have the first item displayed. 
5. Share the profile.

Gecko profile:
https://perfht.ml/2q0q2Yr

Notes:
https://docs.google.com/spreadsheets/d/1Kxn850VasyaG_WfRg3pMInW0hbIT8LP7pRPBYTIpdbM/edit?pli=1#gid=679575660
(Reporter)

Comment 1

11 months ago
https://perfht.ml/2ryKu1d
Here's the Gecko profile obtained on Acer Aspire e15.
Version: 55.0a1
Windows 10 64 bit
buildID: 20170518030213
Assignee: nihsanullah → nobody
Blocks: 1370336
Summary: STR Facebook group first item is displayed → Facebook group navigation start: group first item is displayed
Whiteboard: [QRC][QRC_NeedAnalysis]

Comment 2

10 months ago
Mason, please do an analysis on the gecko profile in comment 1. Thanks!
Assignee: nobody → mchang
Mason, is the dependency going in the right direction with this and bug 1373816 and bug 1373815?
(In reply to Milan Sreckovic [:milan] from comment #3)
> Mason, is the dependency going in the right direction with this and bug
> 1373816 and bug 1373815?

Yeah. I think we should just reprofile once those two are done. Those seemed to be the biggest chunk to me.
As in, doing bug 1373816 and bug 1373815 has an effect on this one.  I would have had this bug then depend on those two, not this one block those two, but as long as we have the notes and the common understanding, I'm good.
Depends on: 1379001
Bug 1379001 comment 18, based on an updated profile (https://perfht.ml/2eNLCMk) suggests we need follow up bugs in JS and layout.
Jean, what's the process - should I just created JS and layout bugs linked to this?
Flags: needinfo?(jgong)

Comment 9

8 months ago
Yes, Milan. Please help to create bugs per comment 7 and link to this bug. Thanks.
Component: General → JavaScript Engine
Flags: needinfo?(milan)
Whiteboard: [QRC][QRC_NeedAnalysis] → [qf][QRC][QRC_Analyzed]

Updated

8 months ago
Flags: needinfo?(jgong)
Dropping [qf] tag (triage nomination) -- this is already [QRC] which I think means there's no need for additional triage.
Whiteboard: [qf][QRC][QRC_Analyzed] → [QRC][QRC_Analyzed]
Assignee: mchang → nobody
Adding a "[qf]" whiteboard tag so this old bug tagged "[QRC_Analyzed]" but not "[qf" will be re-triaged.
Whiteboard: [QRC][QRC_Analyzed] → [QRC][QRC_Analyzed][qf]

Comment 12

3 months ago
Alin, can you please do an updated profile for us since the current one is old.
Flags: needinfo?(arus)
(Reporter)

Comment 13

3 months ago
Hi Jean, sure, I've attached a new profile with the last nightly(20180130102929) on Acer Aspire machine:

https://perfht.ml/2EpbQxz

p.s. sorry for delay, I was in PTO :)
Flags: needinfo?(arus)
Here's that same profile link, but now with the Facebook content process (#3 of 3) selected:
 https://perfht.ml/2nnyUp1

Comment 15

3 months ago
Dietrich, 
we have an updated profile. Can you do an analysis and see what surfaces? Thanks!
Flags: needinfo?(dietrich)

Updated

3 months ago
Whiteboard: [QRC][QRC_Analyzed][qf] → [QRC][QRC_NeedAnalysis][qf]
Started poking around in dholbert's profile, which has a series of hangs in the 4-5ish second range of the profile:

* The first hang occurs after a load event that seems to trigger an animation (from the looks of it), looks like getting offsetHeight on some element repeatedly (https://i.imgur.com/Nz9HQPK.png ), which causes a reflow party.

* The second hang occurs after a series of pageshow events followed by a load event (200ms) and a DOMTitleChange event, then looks like a bunch of React state calculation going on.

* The third hang looks like a React tree reconciliation that also turns into a reflow party due to some element size queries: https://i.imgur.com/NjTtJvr.png
Jean, it looks like they're doing a whole bunch of things that guarantee jank, eg: piling reflows on top of reflows by animating in crude fashion.

It doesn't mean there's nothing to fix on our end - this looks like a death-by-1000-cuts scenario. Fixing some things that might have small individual wins but that are in the critical path of common web rendering workflows might have a huge impact, and could be hiding in there.

It would be good to have a more experienced profile-reader than myself do a quick pass on it, as well as someone who's more familiar with the set of QF issues that are already triaged, which might have impact here.
Flags: needinfo?(dietrich) → needinfo?(jgong)

Comment 18

2 months ago
Bas,  Based on Dietrich's comment#17 can you take a deeper look at the profile and potentially break down the issues into the specific problem areas or more distinct bug(s).
Flags: needinfo?(jgong) → needinfo?(bas)
(In reply to Jean Gong :jgong from comment #18)
> Bas,  Based on Dietrich's comment#17 can you take a deeper look at the
> profile and potentially break down the issues into the specific problem
> areas or more distinct bug(s).

I have to mostly agree, I can't find a single 4-5 second hang in there but there's a series of shorter ones amounting to that as far as I can tell. Maybe he looked at a different profile? I looked at https://perfht.ml/2nnyUp1, that whole profile is only 9 seconds as far as I can tell.

There's a bunch of issues in the painting department here which are already being looked at on the painting side (like displaylist building or frame layer building aren't great), but none of those are responsible for particularly long hangs (although they certainly need improvement). Overall the largest contributer I can see is JS code, but not one particular part of that stands out as the culprit, I'm not sure this is very actionable other than 'we need to make JS faster'. Maybe someone with more expertise in JS or DOM can identify other things.
Flags: needinfo?(bas)
> I have to mostly agree, I can't find a single 4-5 second hang

(To clarify, I think dietrich's comment 16 was talking about shorter hangs that happen at around 4 to 5 seconds into the profile)

Comment 21

2 months ago
Panos,  can you please take a look at this bug. It doesn't seem to fall under QF since the team looked at the profile and its not clear where the real issue lies.  Mconley recommended that we ask you since this could be something you are doing longer term related to Devtools.
Flags: needinfo?(past)

Updated

2 months ago
Whiteboard: [QRC][QRC_NeedAnalysis][qf]
Xidorn, do you see anything actionable in this profile from comment 14?
Flags: needinfo?(past) → needinfo?(xidorn+moz)
Whiteboard: [perf-tools]
In terms of rendering, I don't really see much thing actionable from the profile.

I used the range mentioned in comment 16 and comment 20, which contains a long read bar in the timeline. In the total range of ~1s, there is 128ms under "FlushPendingNotifications", in which 51ms is triggered by vsync tick, 71ms is triggered by script query, and 6ms from event handling. Other than that, it seems majority of time is in compiling and executing the script.

For analyzing tooling, there is an obvious perf.html bug to fix which is devtools-html/perf.html#644. It can be seen that many reflows are not correctly marked in the timeline due to nested tracing markers.

There are several 10ms and 18ms restyle can be seen, which sounds significant. We may want to analyze further whether they are reasonable. It may help if the profile can contain some of the statistics we collect in TraversalStatistics [1] especially elements_{traversed,styled,matched}. Given that when we do parallel traversal, we cannot (and do not want to) record details inside style threads into profile by default, those statistics can be an important clue for whether a restyle is interesting.

Also, time spent in script is probably not very useful for people who are not working on the JS engine, so it would be helpful if we can drop all samples which end up being inside script (rather than, e.g. Web API calls into C++). Since the stack and function of script execution can be versatile, and they can sometimes call into API which we are interested, so it can be pretty hard to filter. It is basically a reverse of devtools-html/perf.html#758, but the idea is probably similar.


[1] https://searchfox.org/mozilla-central/rev/33cc9e0331da8d9ff3750f1e68d72d61201176cb/servo/components/style/context.rs#295-327
Flags: needinfo?(xidorn+moz)
With devtools-html/perf.html#644 and bug 1444296 fixed, it would be a good idea to get another profile with this issue to see if we can get any more information from it.
You need to log in before you can comment on or make changes to this bug.