PackageManager: Load packages lazily on dub build#2500
Conversation
getBestPackage is intended to find the highest local version matching a range. Due to this, it has to eagerly load packages and iterate through them. However, when loading a resolved dependency, we have an exact Version, which is simply wrapped in a VersionRange, so we can call getPackage instead.
|
CI failing though |
Possibly unrelated but still worrying. |
Seem related |
|
Yeah errors are related. I solved one already, looking into the others. |
Geod24
force-pushed
the
lookup-linear
branch
3 times, most recently
from
000c80a to
74bf4f2
Compare
A problem of the current design of dub is that all locations are scanned, regardless of what action is being performed, often multiple times. With this change, a regular `dub build` on a project with all dependencies resolved will no longer loads all available package, which can substantially speed up development.
|
This came together quite nicely. For reference, on my machine, with ~198 packages, this shortened start-up time by 120ms. |
What was the absolute start-up time before? |
|
It varies but in the 6s range. |
|
What do you mean by startup in this case? |
|
Right, my benchmark was on a simple |
| { | ||
| // See `m_initialized` documentation | ||
| if (!this.m_initialized) | ||
| this.refresh(); |
There was a problem hiding this comment.
whenever I see this pattern I think "shouldn't refresh handle the check?"
There was a problem hiding this comment.
refresh can be called multiple times and depends on the environment, so it can't decide "on its own" to skip a run.
Maybe having a simple this.checkInitialized() function would be a bit more self-contained, though.
5 participants
Implements the solution outlined here.
Fixes #2338