gregtatum

Understanding how DevTools multiprocess architecture works.

The following is a diagram that details the multiprocess architecture of DevTools. The intent is to provide an overall picture into which code is loaded where, why, and with what priviliges.

 ________________________________________________________________________________________
|                                   Parent process                                       |
|----------------------------------------------------------------------------------------|
|                                                                                        |
|  DevTools Toolbox (there can be multiple instances)                                    |

gregtatum

/* @flow */
import type { Wrapped } from './wrap';
import { wrapWithSideEffect } from './wrap';

function addOne(a) {
  return a + 1;
}

type AddOne = typeof addOne;

gregtatum

/* This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
// @flow

import * as React from 'react';
import { connect } from 'react-redux';
import type {} from 'react-redux';
import type { Dispatch, State } from '../types/store';

gregtatum

changeset:   392160:39c32b684ff7
user:        Greg Tatum <gtatum@mozilla.com>
date:        Wed Nov 15 11:27:47 2017 -0600
summary:     Flow typing devtools/server/main.js

diff --git a/.hgignore b/.hgignore
--- a/.hgignore
+++ b/.hgignore
@@ -81,17 +81,17 @@
 # Git repositories

gregtatum

Understanding how DevTools multiprocess architecture works.

 ________________________________________________________________________________________
|                                   Parent process                                       |
|----------------------------------------------------------------------------------------|
|                                                                                        |
|  DevTools Toolbox (there can be multiple instances)                                    |
|                                                                                        |
|   - DevTools client code and panels (devtools/client)                                  |

gregtatum

Perf bottleneck with using console in perf.html development

In perf.html development mode, console ends up being a bottleneck on performance. In development mode, perf.html logs messages of timing information for individual functions, and logs the entire redux state on every action dispatch. In console, the newly introduced message batching the behavior has helped contain the impact of these frequent updates quite a bit, but a large amount of time is still being spent in React. Here is an example profile, where the content thread is running perf.html, and doing a non-trivial amount of work in rapid succession, with lots of console.log() messages. The content thread is a bit slow, but is healthy in being able to redraw the screen in a non-blocking manner.

https://perfht.ml/2xblTpm

The main thread contains DevTools' client code, and each batch of updates from content, is followed by a long single update of the console's React components. These end up being long pauses of 170-280ms dealing with the batched

gregtatum

// @flow
import React, { PureComponent } from 'react';
import ReactCSSTransitionGroup from 'react-addons-css-transition-group';
import ButtonWithPanel from '../components/ButtonWithPanel';
import ArrowPanel from '../components/ArrowPanel';
import { selectedThreadSelectors, getLastAddedFilter } from '../reducers/profile-view';
import { getPruneFunctionsList, getPruneSubtreeList, getSelectedThreadIndex } from '../reducers/url-state';
import { connect } from 'react-redux';
import {
  pruneFunction,

gregtatum

These two logs show a working and broken GL call example. When there is only one uniform active, the draw call works, but when two uniforms are active, the values do not get set and are 0. The draw calls work with either one active, but not with both active. The program is all written in Rust, and uses an FFI to talk to the gl context.

gregtatum

/* This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/. */

import React, { PropTypes, PureComponent } from 'react';
import { connect } from 'react-redux';
import ProfileUploadField from './ProfileUploadField';
import classNames from 'classnames';
import AddonScreenshot from '../../../res/gecko-profiler-screenshot-2016-12-06.png';
import PerfScreenshot from '../../../res/perf-screenshot-2017-05-11.jpg';

gregtatum

const rootNode = {
  childCount: 0,
  message: undefined,
  childA: undefined,
  childB: undefined
}

// Add a message to the binary tree in a balanced manner
// UPDATE: This won't work because it makes the nodes out of order.
function addMessage (node, message) {