1363424 - Facebook group navigation start: group first item is displayed

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Alin Rus]

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

Comment 1

[Alin Rus]

https://perfht.ml/2ryKu1d
Here's the Gecko profile obtained on Acer Aspire e15.
Version: 55.0a1
Windows 10 64 bit
buildID: 20170518030213

Comment 2

[Jean Gong :jgong]

Mason, please do an analysis on the gecko profile in comment 1. Thanks!

Comment 3

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

Mason, is the dependency going in the right direction with this and bug 1373816 and bug 1373815?

Comment 4

[Mason Chang [Inactive] [:mchang]]

(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.

Comment 5

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

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.

Comment 6

[Mason Chang [Inactive] [:mchang]]

Updated Profile: https://bugzilla.mozilla.org/show_bug.cgi?id=1373816#c6

Comment 7

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

Bug 1379001 comment 18, based on an updated profile (https://perfht.ml/2eNLCMk) suggests we need follow up bugs in JS and layout.

Comment 8

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

Jean, what's the process - should I just created JS and layout bugs linked to this?

Comment 9

[Bobby Chien]

Yes, Milan. Please help to create bugs per comment 7 and link to this bug. Thanks.

Comment 10

[Daniel Holbert [:dholbert]]

Dropping [qf] tag (triage nomination) -- this is already [QRC] which I think means there's no need for additional triage.

Comment 11

[Chris Peterson [:cpeterson]]

Adding a "[qf]" whiteboard tag so this old bug tagged "[QRC_Analyzed]" but not "[qf" will be re-triaged.

Comment 12

[Jean Gong :jgong]

Alin, can you please do an updated profile for us since the current one is old.

Comment 13

[Alin Rus]

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 :)

Comment 14

[Daniel Holbert [:dholbert]]

Here's that same profile link, but now with the Facebook content process (#3 of 3) selected:
 https://perfht.ml/2nnyUp1

Comment 15

[Jean Gong :jgong]

Dietrich, 
we have an updated profile. Can you do an analysis and see what surfaces? Thanks!

Comment 16

[Dietrich Ayala (:dietrich)]

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

Comment 17

[Dietrich Ayala (:dietrich)]

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.

Comment 18

[Jean Gong :jgong]

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).

Comment 19

[Bas Schouten (:bas.schouten)]

(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.

Comment 20

[Daniel Holbert [:dholbert]]

> 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

[Jean Gong :jgong]

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.

Comment 22

[Panos Astithas (he/him) [:past] (please ni?)]

Xidorn, do you see anything actionable in this profile from comment 14?

Comment 23

[Xidorn Quan [:xidorn] UTC+10]

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

Comment 24

[Panos Astithas (he/him) [:past] (please ni?)]

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.

Comment 25

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.

Comment 26

[Bryan Thrall [:bthrall]]

Closing as INCOMPLETE as suggested by Release mgmt bot because there has been no activity in the last 5 years.

Please re-open this bug if there are updates or it is still being worked on.