changing profile-logic for network panel

After working on #1110, I’ve realized we might have to create a new profile logic for the network panel.

Right now we use the tracing markers as our data source: https://github.com/devtools-html/perf.html/blob/65796f2124f7e67bfbab28438126682edf78b51c/src/profile-logic/profile-data.js#L1309

But this seems not a 100% fit for our needs as we either get a marker with startTime and endTime, so we can display the duration (this is good) or we just get the startTime and no duration (not so good). One possibility would be, we could display the startTime as a vertical stroke, but I am not sure if this would improve the quality of the data visualization.

Another idea that @gregtatum did bring up today was to use http://www.softwareishard.com/blog/har-12-spec/#timings (which I also discussed with @mstange last week). This is the data we are using for the network panel in devTools. That would be definitely be interesting for the network sidebar.

What are your thoughts on this @gregtatum @mstange @past @julienw?

[gregtatum]

Also, this is a useful profile with network markers: https://perfht.ml/2KZ0vtS

Useful snippets for the console:

var network = filteredThread.markers.data.filter(data => data && data.type ==='Network');
var start = network.filter(data => data.status === 'STATUS_START')
var stop = network.filter(data => data.status === 'STATUS_STOP')
var redirect = network.filter(data => data.status === 'STATUS_REDIRECT')

[gregtatum]

Right now we construct MarkerTiming to display the markers. The format was chosen to minimize GC when we slice and dice up the profiles to render the markers, and be fast to iterate over while the markers are drawn via 2d canvas. The new network panel is going to use the DOM, so it might not need the same shape of data.

export type MarkerTiming = {
  // Start time in milliseconds.
  start: number[],
  // End time in milliseconds.
  end: number[],
  index: IndexIntoTracingMarkers[],
  label: string[],
  name: string,
  length: number,
};

To think out loud in code, maybe the network panel could use something like this.

type NetworkTiming = {|
  +domainLookupStart: Array<Milliseconds>,
  +domainLookupEnd: Array<Milliseconds>,
  +connectStart: Array<Milliseconds>,
  +tcpConnectEnd: Array<Milliseconds>,
  +secureConnectionStart: Array<Milliseconds>,
  +connectEnd: Array<Milliseconds>,
  +requestStart: Array<Milliseconds>,
  +responseStart: Array<Milliseconds>,
  +responseEnd: Array<Milliseconds>,
  +URI: Array<string | null>,
  +count: Array<number>,
  +isRedirect: Array<boolean>,
  +length: number,
|};

export function generateNetworkTiming(markers: MarkersTable): NetworkTiming {
  const toNetworkTimingIndex: Map<number, number> = new Map();
  const networkTiming = {
    domainLookupStart: [],
    domainLookupEnd: [],
    connectStart: [],
    tcpConnectEnd: [],
    secureConnectionStart: [],
    connectEnd: [],
    requestStart: [],
    responseStart: [],
    responseEnd: [],
    URI: [],
    count: [],
    isRedirect: [],
    length: 0,
  };

  for (let markerIndex = 0; markerIndex < markers.length; markerIndex++) {
    const data = markers.data[markerIndex];
    if (!data || data.type !== 'Network') {
      continue;
    }
    
    // Get the correct timing index based on the payload's unique ID.
    // There can be multiple markers for a single network event.
    let networkTimingIndex = toNetworkTimingIndex.get(data.id);
    if (networkTimingIndex === undefined) {
      networkTimingIndex = networkTiming.length++;
      toNetworkTimingIndex.set(data.id, networkTimingIndex);
    }
    
    switch (data.status) {
      case 'STATUS_START':
        // We know there is a start, but don't have more detailed timing.
        break;
      case 'STATUS_REDIRECT':
        // Fill in the redirect and timing information.
        break
      case 'STATUS_DONE':
        // Fill in the timing information.
        break;
      default:
        throw new Error('Unknown network payload type');
    }
  }
  return networkTiming;
}