Skip to content

Parallel fetching of available versions #2280

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

Merged
merged 31 commits into from
Jan 14, 2020
Merged

Conversation

sigurdm
Copy link
Contributor

@sigurdm sigurdm commented Dec 16, 2019

Implements rate-limited parallel fetching of version information when solving.
Also does speculative pre-fetching of version information of dependencies of the newest versions of each package.

In informal benchmarks of pub get for a package whose only direct dependency is package:test the resolution time goes from 7.8 seconds to 1.5 seconds.

Also adds package:pedantic to our runtime dependencies

@sigurdm
Copy link
Contributor Author

sigurdm commented Dec 17, 2019

This messes up the zones. That needs to be fixed to land this.

@sigurdm
Copy link
Contributor Author

sigurdm commented Dec 17, 2019

the zones should work correctly now

@jonasfj
Copy link
Member

jonasfj commented Dec 17, 2019

Fixes #2147 \o/

Copy link
Member

@jonasfj jonasfj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some initial comments, I'll have more :)

Copy link
Member

@jonasfj jonasfj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor risk of race condition in Retriever... and minor concern about pre-fetching starting implicitly, but needing to be explicitly terminated.

@sigurdm sigurdm requested a review from jonasfj December 30, 2019 12:26
Copy link
Contributor Author

@sigurdm sigurdm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the review!

Copy link
Member

@jonasfj jonasfj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just nits, this seems solid.

Copy link
Member

@jonasfj jonasfj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@natebosch, if you have any more drive-by comments now is the time to make them, otherwise we'll land this :)

@jonasfj
Copy link
Member

jonasfj commented Jan 13, 2020

oh, I guess we'll also have to fix the travis tests.. but we'll land this soon :)

if (_started.contains(task.jobId)) {
return;
}
_started.add(task.jobId);
Copy link
Member

@natebosch natebosch Jan 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[nit] I usually prefer to skip the .contains before a .add on a Set.

if (!_started.add(task.jobId)) {
  return;
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

}
_started.add(task.jobId);

Future<V> runJob() async {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need a separate function for this? Can we instead do

completer.complete(task.zone.runUnary(_runJob, task.jobId));

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is to handle the case that _runJob throws sync exceptions
Added an explanatory comment

@sigurdm sigurdm merged commit 429a060 into dart-lang:master Jan 14, 2020
@sigurdm sigurdm deleted the parallel_get branch January 14, 2020 15:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants