1378734 - [meta] Use the profiler to optimize DevTools startup

Status: NEW

(DevTools :: General, enhancement, P3)

Description

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Use the profiler to get more granular information about hotspots and create workarounds… we should pay special attention to loops, especially when they call code that loops.

Filter on EdgarMallory

Comment 1

[Alexandre Poirot [:ochameau]]

Attachment: toolbox opening profile

Here is a profile of toolbox opening with the inspector against a naive document (data:text/html,foo)
https://perfht.ml/2v65zVZ

Attached, a screenshot of this profile with some labels to help understanding what is the current state of our codebase.

There is x steps:
* Load the framework (devtools.js, devtools-browser.js and all its dependencies) this is Group A,
* Load toolbox document (toolbox.xul) this is 6 and Group B,
* Init the toolbox and setup server in the parent process, this is 9 and group C,
* Spawn a server in the child process and retrieve the tab actor, this is 11, 12 and 13,
* Build toolbox UI, from 14 to 17,
* Create inspector actors, from 18 to 20, but also later 22 and 23,
* Load inspector document (inspector.xhtml), this is around step before, during and after step 21,
* Build inspector UI, this is Group D and from 27 to 29,
* Query the inspector actor with various request, step 31.
* Finally, some various lazy steps like starting performance actor and finalizing toolbox ui, steps 30 and 32.

Here is some more details on all steps:

Group A: devtools-startup.js:initDevTools()
  1: Loader.jsm: setProvider > loader.js: Loader constructor > regexp creation for module mapping
  2: require(definitons.js) > require(l10n)
  3: devtools.js: new DevTools() > registerDefaults()
  4: devtools-browser.js: gDevToolsBrowser.addToolsToWindow
  5: devtools-browser.js: gDevToolsBrowser._registerBrowserWindow > addMenus + updateCommandAvailability

6: devtools-startup.js: onKeyShortcut > toogleToolboxCommand
Group B: toolbox.xul document load (loadURI, paint, ...)
  7: clientHeight > restyle
  8: xulElement::setAttribute 

9: require(toolbox > attach-thread and browser-loader) + getStr + new Toolbox()
Group C: toolbox.open 
         > DebuggerServer.connectPipe/registerActors, new BrowserLoader()
  10: require(server/main) > require(actors/common) > require(protocol), require(transport)

11: DebuggerClient.getTab
12: loadFrameScript(child.js)
13: receive debug:connect message and RootActor.getTab() > load ExtensionContent.jsm

14: Toolbox._mountReactComponent
15: Toolbox.setCanRander
16: Toolbox.selectTool
17: Toolbox.setToolboxButtons

18: require(actors/styles)
19: require(actors/highlighters)
20: getHighlighter

21: load inspector.js (require(markup, grid-inspector, store))

22: getCSSDatabase
23: getPageStyle

Group D: Inspector._deferredOpen
  24: updateDebuggerPausedWarning (require(notification-box))
  25: addExistingTab > addTab > React
  26: require(layout.js, font.js) + new LayoutView()
27: SwatchColorTooltip
28: codemirror bundle load
29: onMarkupFrameLoad

30: require(node/os), then require(fronts/performance), and buildNoAutoHideButton

31: various rdp request on the inspector actors

32: loading performance actor and "connect" it

Comment 2

[Patrick Brosset <:pbro>]

Alex: is this something you are working on? Or perhaps you're working on bugs that should block this one?
Just trying to make sure we have a good handle on which bugs are in progress and which aren't.

Comment 3

[Alexandre Poirot [:ochameau]]

This bug looks like a meta bug where we will open specific ones based on profiler data.
comment 1 is a way to explain everyone the current state of our tool and help trying to focus on one piece and jump on it.
I opened bugs 1392562 (I'm not actively looking at it), 1393086 (actively looking, but waiting for people to give it a try).
I would be happy if people start opening bugs based on profiler data, as I do.