Skip to content
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

Introduce computedArtifacts #583

Merged
merged 21 commits into from
Aug 20, 2016
Merged

Introduce computedArtifacts #583

merged 21 commits into from
Aug 20, 2016

Conversation

paulirish
Copy link
Member

@paulirish paulirish commented Aug 11, 2016

There are a few in-between artifacts that have been generated from the trace & networkRecords. However they can be lazily created, which simplifies the scheduling of items like speedline, and reduces complexity when importing artifacts from the config.

Additionally, this also means we can cache the results of our computedArtifacts, which will speed up generation of speedline, DevtoolsTimelineModel, and TracingModel.

This PR moves 3 gatherers into be computedArtifacts: speedline, screenshots, and critical network chains.

Once landed, I'll followup with porting DevtoolsTimelineModel, and TracingModel into the same setup. (With the latest version of speedline, we can now pass a complete DevtoolsTimelineModel into it, the same we'll share for our own measurements. This will take care of another ~1-4s of latency during reporting)

fixes #542

paulirish and others added 18 commits August 3, 2016 11:35

Verified

This commit was signed with the committer’s verified signature.
BryanttV Bryann Valderrama

Verified

This commit was signed with the committer’s verified signature.
BryanttV Bryann Valderrama

Verified

This commit was signed with the committer’s verified signature.
BryanttV Bryann Valderrama

Verified

This commit was signed with the committer’s verified signature.
BryanttV Bryann Valderrama

Verified

This commit was signed with the committer’s verified signature.
BryanttV Bryann Valderrama

Verified

This commit was signed with the committer’s verified signature.
BryanttV Bryann Valderrama

Verified

This commit was signed with the committer’s verified signature.
BryanttV Bryann Valderrama

Verified

This commit was signed with the committer’s verified signature.
BryanttV Bryann Valderrama

Verified

This commit was signed with the committer’s verified signature.
BryanttV Bryann Valderrama

Verified

This commit was signed with the committer’s verified signature.
BryanttV Bryann Valderrama
@paullewis
Copy link
Contributor

I'm not clear on exactly what the change proposes. How does computedArtifacts sit alongside artifacts?

@paulirish
Copy link
Member Author

@paullewis

#542 has some backstory, but I'll elaborate here. This was motivated by two things:

  1. Currently a lighthouse run builds a traceviewer model multiple times (in EIL and TTI). It creates a devtoolstimelinemodel multiple times as well (user-timings, screenshots, and again inside of speedline). Each of these models builds costs 700ms-2000ms depending on the trace. To speed up the run, I'd like to make sure we only build our models just once and pass that around.
    • This would mean turning these models into gatherers. But that's unfortunate as they don't really have to be scheduled against a pass. And I'd prefer to not build these models in-between our gatherers.
    • More importantly, screenshots depends on devtoolstimelinemodel (and speedline soon will), but as gatherers they'll all be siblings, which will lead to some awkward configuration to manage this scheduling.
  2. When lighthouse accepts a trace as input it has to reach back into speedline in order to present it as an artifact. And then with the change I just described above, it will have to do the same but for all of these components, sequenced correctly. This hardcodes too much knowledge about our artifact dependencies right into our configuration management.

How does computedArtifacts sit alongside artifacts?

This PR makes a semantic change between these two categories.

  • gatherers all speak directly to the browser and collect data. All of them talk to the protocol
  • computed artifacts do not talk to the protocol. They take either a trace or networkRecords and generate another artifact that's of value to more than 1 audits. (if they're only ever going to be useful to 1 audit, then their work might as well be done inside the audit)

And lastly, functionally, this PR adds an async interface onto the artifacts object that allows any audit to request one of these computedArtifacts. artifacts.requestSpeedline(trace).then( ....

@paulirish paulirish merged commit c8662e3 into master Aug 20, 2016
@paulirish paulirish deleted the derived branch September 19, 2016 01:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Derived artifacts
3 participants