1619080 - Smiley-Panel of WhatsApp-Web takes 1-2s to appear

Status: RESOLVED INVALID

(Core :: JavaScript: GC, enhancement, P2)

Description

[Clemens Eisserer]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

• used WhatsApp-Web on my Arrandale based laptop (i5 540M, 2 Cores + Hyperthreading, 3Ghz boost). This is quite an old machine, however it is performance-wise still compareable to current netbooks or cheap laptops with Atom or Pentium/Celeron Silver or ARM powered devices.

The machine was using the traditional OpenGL compositor.

Actual results:

• when clicking on the smiley-panel it takes 1-2s for the panel to appear. this introduces noticeable delay when typing messages.

Expected results:

• the panel should appear at least as fast as it does when using Google Chrome.
  There it appears with a slight delay of ~250ms, which is barely noticeable.
  So while this panel does seem to be implemented in a rather unoptimized way, chrome seems to cope a lot better.

Please find the Gecko Profiler data at: http://bit.ly/3adzADq

Youtube-Video with Firefox (please note the delay between the click noise and the panel appearance): https://youtu.be/ycG3tf3iRqM
Video of the same action performed with Chrome: https://youtu.be/OPxDLIhyGj8

Comment 1

[Daniel Bodea [:danibodea]]

I attempted to reproduce but I am not sure this is valid. I have timed the opening of the smiley-panel on different macs, linux or windows systems with varying performance capabilities (including an HP laptop with an i3-5505U and 4 GB of RAM with Ubuntu 18) and all the s7ystems opened the panel in about 1 second. One mention: On first open of WhatsApp Web, the panel opens in about 1 second, but renders the actual smileys in about 1-4 seconds intermittently; only on first panel open.

All these behaviors are also observed on the Chrome browser.

I am setting the component to (Core) Performance in the hope that someone will pick it up and have an opinion on the logs attached.
If the component is incorrect, please set a more appropriate one.

Thank you for your contribution!

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Surprisingly lots of minor GCs, and they end up taking quite a bit time when handling click.
Perhaps GC folks have some opinion.

Comment 3

[Steve Fink [:sfink] [:s:]]

It seems to be allocating >200MB/sec of strings (tenuring 180MB/sec or so). The minor GCs are from filling up the string store buffer, meaning that it's allocating lots of strings in the nursery and storing them in tenured objects. The minor GCs are 2-3ms, though, and account for maybe ~200ms of the delay.

It might be better if string pretenuring kicked in, but I'm not sure -- the minor GCs are still discarding around 20% of the strings, so that could easily make things worse.

Comment 4

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

The minor GCs are caused by loading emoji regex, [1]. (there are more, I just list one of them causing minor GC here)
Pretenuring won't help on this. In this case the numStringsTenured is almost 12000, and the promotionRate is about ~ 0.2 or 0.3.
I also try this on Chromium, with the flag trace_pretenuring, allocation_site_pretenuring on, the log also shows "don't tenure"

Filed bug 1625230 on GC,

[1]
,#\u20E3,*\u20E3,0\u20E3,1\u20E3,2\u20E3,3\u20E3,4\u20E3,5\u20E3,6\u20E3,7\u20E3,8\u20E3,9\u20E3,\xA9,\xAE,\uD83C\uDC04,\uD83C\uDCCF,\uD83C\uDD70,\uD83C\uDD71,\uD83C\uDD7E,\uD83C\uDD7F,\uD83C\uDD8E,\uD83C\uDD91,\uD83C\uDD92,\uD83C\uDD93,\uD83C\uDD94,\uD83C\uDD95,\uD83C\uDD96,\uD83C\uDD97,\uD83C\uDD98,\uD83C\uDD99,\uD83C\uDD9A,\uD83C\uDDE6\uD83C\uDDE8,\uD83C\uDDE6\uD83C\uDDE9,\uD83C\uDDE6\uD83C\uDDEA,\uD83C\uDDE6\uD83C\uDDEB,\uD83C\uDDE6\uD83C\uDDEC,\uD83C\uDDE6\uD83C\uDDEE,\uD83C\uDDE6\uD83C\uDDF1,\uD83C\uDDE6\uD83C\uDDF2,\uD83C\uDDE6\uD83C\uDDF4,\uD83C\uDDE6\uD83C\uDDF6,\uD83C\uDDE6\uD83C\uDDF7,\uD83C\uDDE6\uD83C\uDDF8,\uD83C\uDDE6\uD83C\uDDF9,\uD83C\uDDE6\uD83C\uDDFA,\uD83C\uDDE6\uD83C\uDDFC,\uD83C\uDDE6\uD83C\uDDFD,\uD83C\uDDE6\uD83C\uDDFF,\uD83C\uDDE7\uD83C\uDDE6,\uD83C\uDDE7\uD83C\uDDE7,\uD83C\uDDE7\uD83C\uDDE9,\uD83C\uDDE7\uD83C\uDDEA,\uD83C\uDDE7\uD83C\uDDEB,\uD83C\uDDE7\uD83C\uDDEC,\uD83C\uDDE7\uD83C\uDDED,\uD83C\uDDE7\uD83C\uDDEE,\uD83C\uDDE7\uD83C\uDDEF,\uD83C\uDDE7\uD83C\uDDF1,\uD83C\uDDE7\uD83C\uDDF2,\uD83C\uDDE7\uD83C\uDDF3,\uD83C\uDDE7\uD83C\uDDF4,\uD83C\uDDE7\uD83C\uDDF6,\uD83C\uDDE7\uD83C\uDDF7,\uD83C\uDDE7\uD83C\uDDF8,\uD83C\uDDE7\uD83C\uDDF9,\uD83C\uDDE7\uD83C\uDDFB,\uD83C\uDDE7\uD83C\uDDFC,\uD83C\uDDE7\uD83C\uDDFE,\uD83C\uDDE7\uD83C\uDDFF,\uD83C\uDDE8\uD83C\uDDE6,\uD83C\uDDE8\uD83C\uDDE8,\uD83C\uDDE8\uD83C\uDDE9,\uD83C\uDDE8\uD83C\uDDEB,\uD83C\uDDE8\uD83C\uDDEC,\uD83C\uDDE8\uD83C\uDDED,\uD83C\uDDE8\uD83C\uDDEE,\uD83C\uDDE8\uD83C\uDDF0,\uD83C\uDDE8\uD83C\uDDF1,\uD83C\uDDE8\uD83C\uDDF2,\uD83C\uDDE8\uD83C\uDDF3,\uD83C\uDDE8\uD83C\uDDF4,\uD83C\uDDE8\uD83C\uDDF5,\uD83C\uDDE8\uD83C\uDDF7,\uD83C\uDDE8\uD83C\uDDFA,\uD83C\uDDE8\uD83C\uDDFB,\uD83C\uDDE8\uD83C\uDDFC,\uD83C\uDDE8\uD83C\uDDFD,\uD83C\uDDE8\uD83C\uDDFE,\uD83C\uDDE8\uD83C\uDDFF,\uD83C\uDDE9\uD83C\uDDEA,\uD83C\uDDE9\uD83C\uDDEC,\uD83C\uDDE9\uD83C\uDDEF,\uD83C\uDDE9\uD83C\uDDF0,\uD83C\uDDE9\uD83C\uDDF2,\uD83C

Comment 5

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

Hi Clemens
I check this again today, however the minor GCs are far less than before( I tried this with Gecko Profiler and with my local build.)
Can you check this again?
I am guessing Whatsapp has updated its web client so the minor-GC problem goes away.

Thanks

Comment 6

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

no activity after 20 months