trace processor - cleanup and fixes ☂️

[paulirish]

Forking off from #14287 …

arch

• Refactor the traceprocessor flow. In short: determine the "inspected" pids/frames in one pass before doing all the subsetting.
• Verify we handle metric calculation of multiple navigations correctly. (For timespan mode)
• While trace-processor could organize all processes found in the trace, I think it's better to just instantly whittle down the events to the "inspected" process tree and frame tree. Drop everything else, so no metric calculation code needs to filter for themselves.
  • or... don't do this since the processFilter is already doing this for us.
• handle the pid reuse case (however unlikely that is while tracing). Having just a map of pid->tid says nothing about the timing. Seems like we might need a temporal aspect to the tracking as well? Or just step though the trace, subsetting in chunks between any FrameCommittedInBrowser events.

frames

• Clarify that frameEvents/frameTreeEvents are a subset of all events from that frame.
• Adopt isOutermostMainFrame?

allframes metrics

• Nearly certain that this fcpAllFrames calculation doesnt return the right value.

• 14760 is relevant..

audit traceEvent usages

• Review all uses of trace.traceEvents as there's potentially a mistake handling pids/frames.
• Audit all uses of .args[.data].frame to see if there's a better way to ensure the data is reliably there.
• Validate all uses of startingPid are using it correctly. (They're probably not)

[connorjclark]

I assume we don't really want to do this housekeeping for our trace processor. Is there anything here that carries over to CDT's trace engine?

[paulirish]

I assume we don't really want to do this housekeeping for our trace processor. Is there anything here that carries over to CDT's trace engine?

• Adopt isOutermostMainFrame?
• verify the allframes thing.
  • and probably.. Let metahandler provide the process overview to all handlers until waiting till finalize.