Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Status
Please ignore this for now; it's for testing.
Results
Most of the 2000ms delays are probably from calls to
await page.waitForTimeout(2000)
, and likely wise with 500ms delays. Fortype
, we should be able to remove2000ms
within a few ms of security-introduced jitter and recover the normal timing, i.e. 81ms and 57ms, a difference of 42%.For
type
a recent run intrunk
resulted in 62.7ms / 63.5ms, a difference of 1.2%. Between measurement methods we have a difference of around 11%.Theoretically these should be equal.
Surprisingly, for
typeContainer
there's a very different characteristic, reporting here at ~67ms and intrunk
at ~20ms, a 3.35x difference. Both are waiting on awaitForTimeout
inserterOpen
is interesting as intrunk
I see 56ms/34ms but in this branch 273ms/935ms, which is both a wild divergence and also flipped in which is faster. It's possible #47750 is impacting the inserter that much, but as a TypeScript conversion PR I don't see anything that should change the runtime in any way. There's nowaitForTimeout()
on this one.