Reuse JSDOM instances across targets #164
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This looks good! At first I had envisioned this to be handled outside of the JSDOMDomProvider (this would improve things for users of happo-plugin-puppeteer as well), but I think the local cache is good as well. I'm going to play around with this locally to see if I can spot anything odd. |
trotzig
reviewed
Jun 18, 2020
| @@ -61,6 +77,17 @@ export default class JSDOMDomProvider { | |||
| return this.dom.window.happoProcessor.init({ targetName }); | |||
There was a problem hiding this comment.
I think inside the happoProcessor (which is src/browser/processor.js) we need to change some things so that the cursor is reset (and possibly other things as well).
|
Looking at the test failures I see this: I've run into this issue before, and I don't know of a workaround (yet). |
I've been investigating a performance problem we ran into at Airbnb the last couple of days. We have some components that end up with very very large dependency graphs, which makes the webpack bundle quite large. Looking at the CI output, it seems to take about 2 min to bundle, which isn't the most terrible thing. But, then I've noticed that the timings for the targets are pretty crazy. Look at these logs: ``` [2020-06-17T19:36:15Z] image_analytics was not bootstrapped [2020-06-17T19:36:37Z] - chrome-medium ✓ (22034.4ms) [2020-06-17T19:38:38Z] No examples found for target chrome-mediumPlus, skipping [2020-06-17T19:38:38Z] - chrome-mediumPlus ✓ (4.0ms) [2020-06-17T19:41:05Z] p3_defer_modals was not bootstrapped ``` Here chrome-medium had examples, so it took snapshots and that took a while which makes sense. mediumPlus didn't have examples, so it took no snapshots. Happo says that mediumPlus took 4ms, but if you look at the timestamps in the log lines, you can see that it actually took 2 minutes. I believe that the time spent on empty targets is in initializing the JSDOM and loading up the webpack bundle. Since we have 6 targets, this adds up to 12 minutes of overhead per job just for loading the bundle, and another 12 if we have to check out previous SHA. This is much too long. I think we can improve performance by reusing the JSDOM instance for all of the targets. In the example above, this should save us about 10 minutes on a run where the previous SHA report exists, and 20 minutes on a run where the previous SHA report does not exist. One potential issue that could arise from this is if there is any side-effecty code in the bundle that looks at the viewport size when it is first executed, that will no longer work quite right since we run the bundle and then resize the window later. In order to preserve backwards compatibility with other DomProvider plugins, like the puppeteer plugin, I left in the width/height in the initialization call, and included a guard around the resize call in case it does not exist yet. We should clean these up in the next breaking change.
lencioni
force-pushed
the
jdl-reuse-jsdom
branch
from
bd16281
to
48cf902
Compare
|
Btw, if you want to iterate quickly on this locally, you can run |
A couple of issues are fixed in this commit: - we can only load the webpack bundle once, so a check for if the happoProcessor is initialized already will prevent infinitely waiting for the init promise. - we need to reset the happoProcessor in between runs, otherwise it won't start back at the top. - we can't close the jsdom window when we're done. Leaving this as a no-op for now, I think this is fine. - expecting the resize call to be async will help make it easier to update happo-plugin-puppeteer. - the init call needs to happen before the resize, now that we reset the happoProcessor as part of the resize.
I removed this in a previous commit, but forgot that happo-plugin-puppeteer isn't calling `happoProcessor.reset()`. Having it in the constructor as well ensures that the iteration works in the puppeteer case as well.
|
After trying this out on our codebase, I'm nervous about merging it. We noticed a number of diffs where state from a different target had spilled over into other targets. For the most part this was okay, but I think it will make Happo more confusing to work with and may make rendering some things not possible. This was mostly problematic for code that read the viewport size and expected it to not change. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
I've been investigating a performance problem we ran into at Airbnb
the last couple of days. We have some components that end up with
very very large dependency graphs, which makes the webpack bundle
quite large. Looking at the CI output, it seems to take about 2 min
to bundle, which isn't the most terrible thing. But, then I've
noticed that the timings for the targets are pretty crazy. Look at
these logs:
Here chrome-medium had examples, so it took snapshots and that took
a while which makes sense. mediumPlus didn't have examples, so it
took no snapshots. Happo says that mediumPlus took 4ms, but if you
look at the timestamps in the log lines, you can see that it
actually took 2 minutes.
I believe that the time spent on empty targets is in initializing
the JSDOM and loading up the webpack bundle. Since we have 6
targets, this adds up to 12 minutes of overhead per job just for
loading the bundle, and another 12 if we have to check out previous
SHA. This is much too long.
I think we can improve performance by reusing the JSDOM instance for
all of the targets. In the example above, this should save us about
10 minutes on a run where the previous SHA report exists, and 20
minutes on a run where the previous SHA report does not exist.
One potential issue that could arise from this is if there is any
side-effecty code in the bundle that looks at the viewport size when
it is first executed, that will no longer work quite right since we
run the bundle and then resize the window later.
In order to preserve backwards compatibility with other DomProvider
plugins, like the puppeteer plugin, I left in the width/height in
the initialization call, and included a guard around the resize call
in case it does not exist yet. We should clean these up in the next
breaking change.