-
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(driver): request smaller trace in m71+ #6117
Conversation
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.
other thoughts:
- we could fix the
FIXME
indriver.getUserAgent
and useBrowser.getVersion
. Then this could be a call to(await driver.getUserAgent()).product
instead of putting it on the pass context - if not, and
hostUserAgent
is just going to be on the pass context until m71, put a TODO? - if you think
hostUserAgent
on there isn't going to be temporary, should we preparse the UA string it so gatherers can just consult the version number?
lighthouse-core/gather/driver.js
Outdated
// TODO(COMPAT): Once m71 ships to stable, change the traceCategories for real | ||
const reChrome71 = /Chrome\/(Headless)?7[1-9]/; | ||
if (passContext.hostUserAgent && reChrome71.test(passContext.hostUserAgent)) { | ||
traceCategories.forEach((cat, idx) => { |
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.
why forEach
? Do we anticipate multiple ones? Maybe this should be changing this._traceCategories
. It's very very unlikely, but in case someone is passing in 'toplevel'
into additionalTraceCategories
and they really mean it :)
could also use map
instead of forEach
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.
maybe this should be reversed as well. Have disabled-by-default-lighthouse
be the default and replaced by toplevel
in Chrome < 71. Then future edits just have to change things here
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.
so it's just RunTask? was that really all it took? 😲 amazing! 😃
@@ -402,6 +401,7 @@ class GatherRunner { | |||
// If the main document redirects, we'll update this to keep track | |||
url: options.requestedUrl, | |||
settings: options.settings, | |||
hostUserAgent: baseArtifacts.HostUserAgent, |
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 was parsing the user agent over in #5893, maybe after this we should do a refactor for some useful host.chromeVersion
, host.isMobile
, host.os
?
I'm mildly nervous about missing some random lantern-impacting event, but I think we've both been through it multiple times before. |
e9a4b6e
to
805e714
Compare
ptal |
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.
so exciting :D lookin' real good
lighthouse-core/gather/driver.js
Outdated
|
||
// In Chrome <71, gotta use the chatty 'toplevel' cat instead of our own. | ||
// TODO(COMPAT): Once m71 ships to stable, drop this section | ||
const milestone = (await this.getBrowserVersion()).milestone; // eg 'Chrome/71.0.3577.0' |
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 feels like this comment should be up where the regex is that parses out 71
:)
@@ -46,9 +48,23 @@ function createActiveWorker(id, url, controlledClients, status = 'activated') { | |||
}; | |||
} | |||
|
|||
function createOnceMethodResponse(method, response) { |
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.
someday using jests mock functions would be awesome :)
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.
yeah our lame driver/connection mocking everywhere is ripe for a cleanup.
createOnceMethodResponse('Browser.getVersion', m70BrowserVersion); | ||
|
||
// eslint-disable-next-line max-len | ||
return driverStub.beginTrace().then(() => { |
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.
want to use async/await
for new code?
getUserAgent() { | ||
return Promise.resolve('Fake user agent'); | ||
const browserVersion = { | ||
protocolVersion: '1.3', |
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.
this doesn't return milestone
. Is this filename wrong and it's really not a fake driver but a fake connection?
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.
good catch. yeah the separation between protocol response vs driver method response got a little mixed up.
Clarified this now.
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.
LGTM!
94d8e30
to
c3e15ca
Compare
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.
since RunTask
is the future, we should also update create-test-trace.js
to use it
const milestone = (await this.getBrowserVersion()).milestone; | ||
if (milestone < 71) { | ||
const toplevelIndex = traceCategories.indexOf('disabled-by-default-lighthouse'); | ||
traceCategories.splice(toplevelIndex, 1, 'toplevel'); |
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.
seems like the splice is unnecessary?
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.
traceCategories[toplevelIndex] = 'toplevel'
sgtm
const SCHEDULABLE_TASK_TITLE_ALT2 = 'ThreadControllerImpl::RunTask'; | ||
const SCHEDULABLE_TASK_TITLE_ALT2 = 'ThreadControllerImpl::DoWork'; | ||
// m65 and earlier | ||
const SCHEDULABLE_TASK_TITLE_ALT3 = 'TaskQueueManager::ProcessTaskFromWorkQueue'; |
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.
have you thought about a long-term support plan for these? Supporting old trace versions seems pretty good if it's not much work, but otoh our test traces are increasingly not looking like traces from master
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.
Yes I'd like to redo all our fixture traces. Right now it doesn't seem too bad..
.. I just tested the perf downside of checking the evt name four times and its probably a maximum of ~10ms total on a big trace. So we can ignore that bit.
I think it's aiight for now. But we'll put something in the OKRs about freshening up our fixtures/mocking/test infra.
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.
yeah, definitely not a performance issue (string compares are fast, especially if they haven't ever been modified), and since the events all more or less cover the subset of events we're interested in (we only have to do the string check, not more convoluted fixes to support each), it's more a case of being able to easily see what the state of the world is in the code.
The downside for updating fixtures (besides being really annoying to do) is we get less coverage of the old versions, so we may want to really phase out support completely for some of these if we actually do that.
@@ -46,9 +48,23 @@ function createActiveWorker(id, url, controlledClients, status = 'activated') { | |||
}; | |||
} | |||
|
|||
function createOnceMethodResponse(method, response) { | |||
assert.deepEqual(!!sendCommandMockResponses[method], false, 'stub response already defined'); |
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.
deepEqual
left over from an earlier revision?
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 wrote the method assuming someone else may try to use it. And just wanted to assert no one was going to use it twice.
I can remove though if you don't see the value.
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 can remove though if you don't see the value.
sorry, I think it's fine, I meant the deepEqual
is kind of overkill because they're both booleans :)
|
||
const mockResponse = sendCommandMockResponses[command]; | ||
if (mockResponse) { | ||
delete sendCommandMockResponses[command]; |
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.
should use a Map for things like this
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 dont see why Map is better, but happy to change it. :)
sg will do. |
Backstory in #3596.
Results: cnn.com's trace goes from 69M to 47M.
--
Browser.getVersion
and parsing out the chrome milestone. We can augment this pattern later forisMobile
andos
like @patrickhulce suggested.on()
andonce()
.disabled-by-default-lighthouse
category and fallback to 'toplevel', as @brendankenny very wisely suggestedSCHEDULABLE_TASK_TITLE
possibilities from FOUR down to 2. But it requires updating a lot of fixture data. So we can do that in a followup.