perf(interop): parallelize and accept tarballs #272
Merged
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
yotamberk
approved these changes
Aug 8, 2020
yotamberk
approved these changes
Aug 8, 2020
|
🎉 This PR is included in version 2.4.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
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.
Parallelization took down about 4 minutes (from 45 to 41, yay!). This was a massive waste of time and with the advantage of hindsight it makes perfect sense, a lot of the stuff we run is already trying to get as much as it can from multicore systems so the utilization is already very high. Plus dependants can't start before their dependencies are done, this pretty much limits parallelization to running Network, Timeline and Graph3D in parallel and everything else in series anyway. I'm keeping it though, because it's a bit faster and since it's all based on promises now, the control flow is much nicer and easier to follow (the projects simply await the promises of their dependencies).
Bigger improvement is that it's now possible to use already built and packed project instead of building it from scratch. This took down about 6 minutes (from 41 to 35 minutes). This basically allows us to add
npm packinto build step and chain interop after it (before this change we would run things likenpm run buildandnpm run testonce as a part of the standard CI and once more with the bit by bit identical code as a part of interop testing).However all these times apply to Vis Dev Utils and we don't make that many changes here, it will be mostly Renovate dealing with this (if it turns out to clog the CI we can tell it to work when we sleep, something like 22:00 through 6:00 UTC?). It doesn't make much of a sense to build the dependencies of packages (e.g. Vis Util for Vis Network) or the sibling packages (Vis Graph3D for Vis Network), it only makes sense to build the dependants (e.g. Vis Charts for Vis Network). What this means is that Vis Dev Utils is the worst case scenario, Vis Util is faster, Vis Data even more and Vis Network took 3 minutes (Vis Charts doesn't have many tests at the moment, we should write some more to make sure our projects actually work with each other).