1326346 - [Perf][Gslide] 23.22%(2308 ms) slower than Chrome when reading a slide with table content on GSlide

Status: RESOLVED DUPLICATE of bug 1330565

(Firefox :: General, defect)

Description

[Shako Ho]

+++ This bug was initially created as a clone of Bug #1315214 +++

# Test Case
STR
1. Open the browser
2. Open the specified Gslide document (https://goo.gl/NAij7l)
3. Wait for loading finished

# Hardware
OS: Windows 7
CPU: i7-3770 3.4GMhz
Memory: 16GB Ram
Hard Drive: 1TB SATA HDD
Graphics: GK107 [GeForce GT 640]/ GF108 [GeForce GT 440/630]

# Browsers
Firefox version: 53.0a1
Chrome version: 55.0.2883.87

# Result
Browser | Run time (median value) 
Firefox | 9942 ms
Chrome  | 7633 ms

Comment 1

[(no longer active)]

Here is a high level analysis of the slowness, based on this profile: <https://clptr.io/2iIJBOP>

The entire run time for loading the slide is 9 seconds.  Out of this time, we spend around 1.879ms initially executing a top-level script when the loading finishes (triggered from nsScriptLoader::EvaluateScript).  After that we process a vsync event and another script load which don't take a lot of time.  The next big chunk of time goes to processing an XHR load event where we spend 2.8 seconds running the JS event handler.  After that we paint, and process another XHR load event which takes about 125ms, then we process another script load through nsScriptLoader::NotifyOffThreadScriptLoadCompleteRunnable::Run, which takes only 39ms, followed by processing the laod event for the page which takes a short amount of time (16ms), followed by another XHR load which takes 167ms, followed by running a timeout which takes 494ms, and then we paint and we're mostly done at this point.

Bug 1330236 and bug 1330249 are two causes of the slowness of executing scripts that I have found so far, besides that it's still not clear to me what else we can obviously improve.

Comment 2

[(no longer active)]

... and we spend 1 *second* reflowing things in response to sync reflows coming from JS.  I filed bug 1330565 for that.

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to Shako Ho from comment #0)
> 2. Open the specified Gslide document (https://goo.gl/NAij7l)

Google tells me "Sorry, the file you have requested has been deleted".

For further-debugging/investigation purposes, is there another doc that we can use as a standard way of reproducing this issue?  (Or is it possible t un-delete the original file?)

Comment 4

[Mike Lien[:mlien]]

please use the new link: https://docs.google.com/presentation/d/1VvEZ9DSIlbjXXXY01wAccMdaF2q9wA1Zx21-nuH3KQc

original file is removed due to some confidential concern, sorry for the inconvenience.

Comment 5

[Daniel Holbert [:dholbert]]

Unfortunately that example doesn't seem to be as good as the original at triggering slow reflow (bug 1330565).  Any chance you could share the original slide privately, or share a modified version of it?  (Or a recreation of something similar to it, with similar contents but no confidential info?)

Comment 6

[Daniel Holbert [:dholbert]]

(If I'd seen the original slide, I could try to do this myself, but unfortunately I didn't ever see it so I'm not sure what sort of contents it had which might be involved in bug 1330565.)

Comment 7

[(no longer active)]

I remember there was some text in the table back when I was looking at it...

Comment 8

[Mike Lien[:mlien]]

Daniel, I will re-generate it again and send you the link.

Comment 9

[:Harald Kirschner :digitarald]

Root cause work now happens in bug 1330565 which will be tracked as part of [qf].

Comment 10

[Kannan Vijayan [:djvj]]

Hi Mike,

Could I get a link to the slide?  I'm trying to repro this and the document seems to have been taken down (re: link https://goo.gl/NAij7l).

Comment 11

[Mike Lien[:mlien]]

you can get the new link here: https://drive.google.com/open?id=1VvEZ9DSIlbjXXXY01wAccMdaF2q9wA1Zx21-nuH3KQc