You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Forking off from #14287 …
arch
pid
reuse case (however unlikely that is while tracing). Having just a map ofpid->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 anyFrameCommittedInBrowser
events.frames
isOutermostMainFrame
?allframes metrics
audit traceEvent usages
trace.traceEvents
as there's potentially a mistake handling pids/frames.The text was updated successfully, but these errors were encountered: