misc(timing): move timing-trace to async events #6440
Conversation
| const startEvt = { | ||
| // 1) Remove 'lh:' for readability | ||
| // 2) Colons in user_timing names get special handling in traceviewer we don't want. https://goo.gl/m23Vz7 | ||
| // Replace with a 'Modifier letter colon' ;) |
| pid: 0, | ||
| tid: trackName === 'measures' ? 50 : 75, | ||
| ph: 'X', | ||
| tid: threadId, |
There was a problem hiding this comment.
I feel like I'm missing something.
I only see one call to this method changed with a threadId isn't this basically the same as what was happening before then?
There was a problem hiding this comment.
Yeah totally the same as before. trackName => threadId has no functional changes, really. with these new events we can't label the track.
not a huge deal anyway.
| expect(consoleError.mock.calls[0][0]).toContain('measures overlap'); | ||
| it('generates a pair of trace event', () => { | ||
| const events = generateTraceEvents(mockEntries[0]); | ||
| expect(events).toMatchSnapshot(); |
| ] | ||
| `; | ||
|
|
||
| exports[`generateTraceEvents generates a pair of trace event 1`] = `Array []`; |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
paulirish
force-pushed
the
timing-trace-async-events
branch
from
2af3faf
to
444be63
Compare
|
thoughts? I've added support for DevTools Perf panel (via adding a TracingStartedInBrowser evt): Though note: -G/-A traces are shown in two diff tracks in chrome:tracing but that's not supported in DevTools: |
| expect(consoleError.mock.calls[0][0]).toContain('measures overlap'); | ||
| it('generates a pair of trace events', () => { | ||
| const events = generateTraceEvents([mockEntries[0]]); | ||
| expect(events.slice(0, 1)).toMatchSnapshot(); |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
| expect(consoleError.mock.calls[0][0]).toContain('measures overlap'); | ||
| it('generates a pair of trace events', () => { | ||
| const events = generateTraceEvents([mockEntries[0]]); | ||
| expect(events.slice(0, 1)).toMatchSnapshot(); | ||
| }); | ||
| }); |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
good call. actually we dont need the ph:'n' now that we're on async events.
problem solved. :)
| } | ||
| } | ||
| } | ||
|
|
||
| /** | ||
| * Generates a chromium trace file from user timing measures | ||
| * Adapted from https://github.com/tdresser/performance-observer-tracing |
There was a problem hiding this comment.
maybe add a note about how threadId is used?
| // 1) Remove 'lh:' for readability | ||
| // 2) Colons in user_timing names get special handling in traceviewer we don't want. https://goo.gl/m23Vz7 | ||
| // Replace with a 'Modifier letter colon' ;) | ||
| name: entry.name.replace('lh:', '').replace(/:/g, '꞉'), |
There was a problem hiding this comment.
😆
maybe do an explicit .replace(/:/g, '\ua789'), just to make it doubly clear that the character is different?
| // 2) Colons in user_timing names get special handling in traceviewer we don't want. https://goo.gl/m23Vz7 | ||
| // Replace with a 'Modifier letter colon' ;) | ||
| name: entry.name.replace('lh:', '').replace(/:/g, '꞉'), | ||
| cat: 'blink.user_timing', |
There was a problem hiding this comment.
it feels like doing this should be possible without faking out a browser trace but w/e traceviewer :)
There was a problem hiding this comment.
traceviewer wont group these but give each measure its own track otherwise
and devtools needs it to view them.
| @@ -50,7 +50,7 @@ function saveTraceFromCLI() { | |||
| // eslint-disable-next-line no-console | |||
| console.log(` | |||
| > Timing trace file saved to: ${traceFilePath} | |||
| > Open this file in chrome://tracing | |||
| > Open this file in DevTools perf panel (or if it's a -G/A run, use chrome://tracing) | |||
There was a problem hiding this comment.
does -G/A run refer to a "-G or an -A run", or a -GA run or a regular run (that did both gathering and auditing)?
|
(with nits :) |
Motivated by #6410
I was avoiding async events for .. mysterious reasons before. But really these will be overlapping, so it makes more sense to be async.
Overlapping happens in promise.all()s often:
Here's how a few timing traces look now:
