1351016 - emoji menu on Twitter takes a long time to populate (5-10 seconds on Firefox vs 1 second on Chrome)

Status: NEW

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Asa Dotzler [:asa]]

The emoji menu on Twitter takes a long time to populate

Steps to reprduce:
1. visit https://twitter.com
2. click the "Tweet" button to compose a new tweet
3. click the "add emoji" smiley face button in the bottom right corner of the compose popup.

Results: user waits many seconds for the emoji menu to populate with all the emojis.

Expected results: emoji menu immediately populated like in other browsers.

Comment 1

[Daniel Holbert [:dholbert]]

Here's a profile of me performing the STR in a fresh profile, after logging into twitter & forcing it to populate a whole bunch of tweets (by scrolling down with the "end" key continuously for ~10 seconds, and then jumping back to the top with "home"):
 https://perfht.ml/2oaksBI

Notes:
* I clicked the emoji button at around 3 seconds, I think, which triggered an initial 638ms event-processing delay for the tab.
* 70% of that time (470ms) is spent in ProcessRestyles, in an extremely-deeply-nested recursive callstack for "Restyle"->"RestyleChildren"->"RestyleContentChildren"->...

Comment 2

[Chris Peterson [:cpeterson]]

On Firefox, the emoji list takes about 5-10 seconds to load all the emoji icons. On Chrome, the emoji icons all appear to load within 1-2 seconds.

Once you've loaded the emoji list, it is fast to reopen in the current tab. If you open Twitter in a second tab, the emoji list is slow to load in the new tab.

This does not seem to be a regression. I tested Firefox ESR 52 and it is slow there, but Nightly 55 feels like it might be a littler slower.

Comment 3

[(no longer active)]

(In reply to Daniel Holbert [:dholbert] (AFK May 3-8, 13-21) from comment #1)
> * 70% of that time (470ms) is spent in ProcessRestyles, in an
> extremely-deeply-nested recursive callstack for
> "Restyle"->"RestyleChildren"->"RestyleContentChildren"->...

Ugh, looking at this profile, this was profiled on a build before bug 1354255, because I do see the profiler labels in the profile which that bug removed, so there is some amount of profiler overhead in this bug.  This should probably be reprofiled.

Comment 4

[Daniel Holbert [:dholbert]]

I'll hope to address this via outreach via bug 1342220 (see bug 1342220 comment 21).  And if that doesn't work, we'll address this via bug 1261484.

I'll add dependencies on each of those bugs and drop the [qf] status from this bug, since it's really kind of a dupe with different STR.

Comment 5

[Ben Kelly [:bkelly, not reviewing]]

Sometimes it doesn't finish loading at all for me.

Comment 6

[Asa Dotzler [:asa]]

Here's a new profile of the hang and slow loading of emoji https://perfht.ml/2vV8ce6

Comment 7

[Cameron McCormack (:heycam)]

I don't see any significant time spent in restyle in that profile.

But what does it mean to be spending so much time in PeekMessage?  Is it anything to do with the TIP hook stuff?  Jim, does anything look awry to you in that profile?

Comment 8

[Asa Dotzler [:asa]]

(In reply to Cameron McCormack (:heycam) from comment #7)
> I don't see any significant time spent in restyle in that profile.

Yeah. And now I can't reproduce that profile.

This is what I can reproduce pretty reliably: https://perfht.ml/2Kyvjyp

Comment 9

[Asa Dotzler [:asa]]

(In reply to Asa Dotzler [:asa] from comment #8)
> This is what I can reproduce pretty reliably: https://perfht.ml/2Kyvjyp

And here's a longer profile that shows not just the initial loading but a mostly loaded list. It seems considerably faster than I remember when I filed this bug. https://perfht.ml/2Kyr9q8

Comment 10

[Asa Dotzler [:asa]]

I've just opened up Chrome and compared and we're much much closer to them in performance than we were a year ago. If there's nothing strange on my last couple of profiles, maybe we can close this bug as worksforme? What do others on this bug see?

Comment 11

[Daniel Holbert [:dholbert]]

I wonder if Asa had loaded a long backlog of tweets when capturing e.g. profile in comment 6?  That's required to trigger jank.

I repeated my STR from comment 1, in latest Nightly on Linux.  Notably: I mash "End" on my keyboard to load a long backlog of tweets -- for ~20 seconds this time, for good measure, and then I scrolled to the top, and then started profiling, clicked in the "compose tweet" box (1.5sec into the profile), and clicked the emoji button (4sec into the profile).

Here's the profile: https://perfht.ml/2Ko7V5W -- still some painfully long restyles there.
 - One 517ms-long restyle when I click the compose button: https://perfht.ml/2jUAL2t
 - 2 long restyles (628ms, 490ms) when I click the emoji button: https://perfht.ml/2jUK9TK

Comment 12

[Emilio Cobos Álvarez (:emilio)]

In a bunch of the later restyles most of the time is spent in networking related code from nsStyleImage::Resolve and such, fwiw.

Comment 13

[Daniel Holbert [:dholbert]]

Interesting finding!

However, those are different (shorter) restyles from the most-problematic ones I was focusing on in comment 11, though.  Here's a profile filtered for "mozilla::net" to illustrate -- the first three restyles (the ~500ms ones noted in comment 11) have no hits for that networking code. (But the later ~100ms restyles do indeed all seem to be mostly networking code inside nsContentUtils::LoadImage.)

Comment 14

[Daniel Holbert [:dholbert]]

(oops, I forgot to paste in the profile link for comment 13. here it is: https://perfht.ml/2jVC5Cj
But anyway, the profile links from comment 11 are better places to start here -- this^ one is just for the narrow issue of those later kinda-slow restyles)

Comment 15

[Jim Mathies [:jimm]]

(In reply to Cameron McCormack (:heycam) from comment #7)
> I don't see any significant time spent in restyle in that profile.
> 
> But what does it mean to be spending so much time in PeekMessage?  Is it
> anything to do with the TIP hook stuff?  Jim, does anything look awry to you
> in that profile?

Looks like we're spending a lot of time waiting on Windows to process a hook callback, and that hook is associated with touchscreen interaction. I guess expected since it appears out of our control since PeekMessage does this internally by design.

Comment 16

[Cameron McCormack (:heycam)]

I still get a similar looking profile: https://perfht.ml/2XRSPAL

The two big restyles when clicking the emoji panel button coming from focus() calls in script. The first is flushing frames, since the focus code needs to be able to call IsFocusable on the element's frame (and apart from frames, needs up to date styles to check e.g. visibility); the second is flushing when notifying IME-related code about a change in focus (bug 1358813 investigated similar).

Comment 17

[Mayank Bansal]

Is this bug still reproducible/relevant?