Slow script warning on initial pageload

RESOLVED FIXED

Status

P2
normal
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: emorley, Assigned: jeads)

Tracking

({perf})

Details

(Reporter)

Description

4 years ago
Broken out from Neil's comment on dev.platform:

> I get a slow script warning in my unoptimised nondebug build when the 
> page first loads :\

We already have bug 1032437 for improving the speed of the first pageload, but Neil's issue sounds more like UI perf and service/API usage related.

Neil, could you post some additional information to help narrow this down? A profiler dump would be great :-)
(Reporter)

Updated

4 years ago
Flags: needinfo?(neil)
(Assignee)

Comment 1

4 years ago
The cause of this issue is identical to bug 1032437 and bug 1032448. Initial profiling indicates we're sending too much data in a single HTTP request. The database round trip is typically less than a second and the UI rendering speed is substantially less than the time it takes to return the data from the server. We can address this by chunking the data returned for the set of pushes/resultsets requested, there's also some caching server side that we could take advantage of to improve page load performance here. I think that this strategy will prevent the slow script warning by reducing the time that the UI is blocking the browser.
(Reporter)

Comment 2

4 years ago
Great, thank you :-)
(Assignee)

Updated

4 years ago
Assignee: nobody → jeads
Status: NEW → ASSIGNED

Comment 3

4 years ago
(In reply to Ed Morley from comment #0)
> Neil, could you post some additional information to help narrow this down? A
> profiler dump would be great :-)

I've never had any luck with the profiler; last time I tried its UI was so slow that I ended up profiling JetPack rather than anything useful. In fact I had trouble just collecting a stack trace from the slow script warning - Firefox ended up crashing, but I did at least get 10 stack frames:

0 anonymous(context = [object HTMLDocument], elem = [object HTMLTableRowElement]) ["https://treeherder.allizom.org/ui/js/index.min.js":2]
    this = function (selector,context){return new jQuery.fn.init(selector,context,rootjQuery)}
1 isHidden(elem = [object HTMLTableRowElement]) ["https://treeherder.allizom.org/ui/js/index.min.js":1]
    this = [object Window]
2 showHide(elements = [object Object], show = true) ["https://treeherder.allizom.org/ui/js/index.min.js":1]
    this = [object Window]
3 anonymous() ["https://treeherder.allizom.org/ui/js/index.min.js":4]
    this = [object Object]
4 anonymous() ["https://treeherder.allizom.org/ui/js/index.min.js":4]
    this = [object Object]
5 anonymous(row = [object Object], jobTdEl = [object Object], jobGroups = [object Object],[object Object],[object Object], resultStatusFilters = success,testfailed,busted,exception,retry,usercancel,running,pending, resultsetId = 238, platformKey = "windows7-32debug", jgObj = true) ["https://treeherder.allizom.org/ui/js/index.min.js":16]
    this = [object Window]
6 anonymous(scope = [object Object], element = [object Object], attrs = [object Object], name = undefined, option = undefined) ["https://treeherder.allizom.org/ui/js/index.min.js":17]
    this = [object Window]
7 nodeLinkFn(childLinkFn = null, scope = [object Object], linkNode = [object HTMLDivElement], $rootElement = undefined, boundTranscludeFn = undefined) ["https://treeherder.allizom.org/ui/js/index.min.js":6]
8 compositeLinkFn(scope = [object Object], nodeList = [object NodeList], $rootElement = undefined, boundTranscludeFn = undefined) ["https://treeherder.allizom.org/ui/js/index.min.js":6]
9 nodeLinkFn(childLinkFn = [function], scope = [object Object], linkNode = [object HTMLDivElement], $rootElement = [object Object], boundTranscludeFn = undefined) ["https://treeherder.allizom.org/ui/js/index.min.js":6]
10 compositeLinkFn(scope = [object Object], nodeList = [object Object], $rootElement = [object Object]) ["https://treeherder.allizom.org/ui/js/index.min.js":6]
Flags: needinfo?(neil)
(Assignee)

Comment 4

4 years ago
We addressed these performance issues by doing the following things:

1.) Reducing the size of data returned from the web service by removing redundant job object property names.

https://github.com/mozilla/treeherder-service/pull/180
https://github.com/mozilla/treeherder-ui/pull/106

2.) Re-structuring the web service requests from the UI so that they are performed in parallel using the $q service in angularjs. I also separated out the retrieval of the resultsets/pushes onto their own web service call. I think this will remove the occasional javascript non-responsive message because the application regains control to render after each request returns. The individual HTTP request round trips are much faster than one single request, by doing them in parallel the end-to-end load time seems very comparable to tbpl.

https://github.com/mozilla/treeherder-service/pull/182
https://github.com/mozilla/treeherder-ui/pull/115

If this is still an issue for anyone please re-open this bug and needinfo jeads.
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(Reporter)

Updated

4 years ago
Keywords: perf

Comment 5

4 years ago
Commit pushed to master at https://github.com/mozilla/treeherder

https://github.com/mozilla/treeherder/commit/8b798b785c40a16ef1461f5adea8716cb832aa70
Remove job property names from resultset web service data to improve page load performance (Bugs 1032437 1032216 1032448 1042621)
You need to log in before you can comment on or make changes to this bug.