-
Notifications
You must be signed in to change notification settings - Fork 9.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
core(trace-of-tab): remove DevTools stableSort dependency #5532
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -32,6 +32,35 @@ class TraceOfTab extends ComputedArtifact { | |
return 'TraceOfTab'; | ||
} | ||
|
||
/** | ||
* @param {LH.TraceEvent[]} traceEvents | ||
* @param {(e: LH.TraceEvent) => boolean} filter | ||
*/ | ||
static filteredStableSort(traceEvents, filter) { | ||
// create an array of the indices that we want to keep | ||
const indices = []; | ||
for (let srcIndex = 0; srcIndex < traceEvents.length; srcIndex++) { | ||
if (filter(traceEvents[srcIndex])) { | ||
indices.push(srcIndex); | ||
} | ||
} | ||
|
||
// sort by ts, if there's no ts difference sort by index | ||
indices.sort((indexA, indexB) => { | ||
const result = traceEvents[indexA].ts - traceEvents[indexB].ts; | ||
return result ? result : indexA - indexB; | ||
}); | ||
|
||
// create a new array using the target indices from previous sort step | ||
const sortedArray = new Array(indices.length); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. should use a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. two inconsistent comments are we making micro optimizations or not ;) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. tested and perf looks pretty much the same either way. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
ha, I thought about that as I was writing it. In theory it helps, but I only suggested it because it's still idiomatic :)
It might even be a little slower in |
||
for (let i = 0; i < indices.length; i++) { | ||
sortedArray[i] = traceEvents[indices[i]]; | ||
} | ||
|
||
return sortedArray; | ||
} | ||
|
||
|
||
/** | ||
* Finds key trace events, identifies main process/thread, and returns timings of trace events | ||
* in milliseconds since navigation start in addition to the standard microsecond monotonic timestamps. | ||
|
@@ -41,16 +70,12 @@ class TraceOfTab extends ComputedArtifact { | |
async compute_(trace) { | ||
// Parse the trace for our key events and sort them by timestamp. Note: sort | ||
// *must* be stable to keep events correctly nested. | ||
/** @type Array<LH.TraceEvent> */ | ||
const keyEvents = trace.traceEvents | ||
.filter(e => { | ||
return e.cat.includes('blink.user_timing') || | ||
e.cat.includes('loading') || | ||
e.cat.includes('devtools.timeline') || | ||
e.cat === '__metadata'; | ||
}) | ||
// @ts-ignore - stableSort added to Array by WebInspector. | ||
.stableSort((event0, event1) => event0.ts - event1.ts); | ||
const keyEvents = TraceOfTab.filteredStableSort(trace.traceEvents, e => { | ||
return e.cat.includes('blink.user_timing') || | ||
e.cat.includes('loading') || | ||
e.cat.includes('devtools.timeline') || | ||
e.cat === '__metadata'; | ||
}); | ||
|
||
// Find the inspected frame | ||
const {startedInPageEvt, frameId} = TracingProcessor.findTracingStartedEvt(keyEvents); | ||
|
@@ -102,14 +127,11 @@ class TraceOfTab extends ComputedArtifact { | |
|
||
// subset all trace events to just our tab's process (incl threads other than main) | ||
// stable-sort events to keep them correctly nested. | ||
/** @type Array<LH.TraceEvent> */ | ||
const processEvents = trace.traceEvents | ||
.filter(e => e.pid === /** @type {LH.TraceEvent} */ (startedInPageEvt).pid) | ||
// @ts-ignore - stableSort added to Array by WebInspector. | ||
.stableSort((event0, event1) => event0.ts - event1.ts); | ||
const processEvents = TraceOfTab | ||
.filteredStableSort(trace.traceEvents, e => e.pid === startedInPageEvt.pid); | ||
|
||
const mainThreadEvents = processEvents | ||
.filter(e => e.tid === /** @type {LH.TraceEvent} */ (startedInPageEvt).tid); | ||
.filter(e => e.tid === startedInPageEvt.tid); | ||
|
||
const traceEnd = trace.traceEvents.reduce((max, evt) => { | ||
return max.ts > evt.ts ? max : evt; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does combining the filter here gain much in performance? It doesn't feel great combined (they don't really have much to do with each other, we just happen to usually do them in pairs) so unless it buys a lot it doesn't feel worth it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it was 3-pronged
was gross
2) avoid another copy of the array since we're introducing a new one here and there were recent issues with large traces hurting people
3) filter inline here was ever so mildly faster on big traces
none of them are particularly strong reasons, so if it's rubbing the wrong way I can go back
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm seeing the perf benefit of the inline filter to be substantial. I think all numbers are under 50ms even for big traces, but it's worth like a 35% speedup.``
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW https://jsperf.com/inline-filter-vs-filter, but filter component is like 1/20th the cost of the sort
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ha, if you're fine on a style level with combining the two steps, @paulirish, I can be fine with it too. Testing it now I see ~5% improvement over all of
_compute()
for a 31MB verge trace (~138ms -> ~131). I was just questioning this part from a code-semantics perspective.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(it's likely not better than 5% because the
filteredStableSort
call goes polymorphic with the second call to it in_compute()
, while AIUI as of Node 10[].filter()
specializes at the callsite, not within.This may get worse as more calls are made, e.g. if someone is running the node module in a loop. You can kind of simulate this by disabling the computed artifact cache and letting
trace-of-tab
run as many times as requested in a-G
run (110 times!). In that case the new method is a little slower (by ~5.3±4ms)All of this is dependent on inlining decisions, though, and how lighthouse itself is run, so perf seems fine either way)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hot chart!
(yeah the code style doesn't bother me too much)