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

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

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.

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.