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
[Get] Only instantiate Repo objects once for items in Packages
.
#276
Conversation
- The old algorithm was O(N^2)... this gives a 3x speedup in null build time for a large project (Zewo).
@mxcl can you review at some point? I'm not entirely sure this is safe, but it is a big win if so. |
Possibly a problem because repo paths change during the Get and Update processes based on which checkouts are selected and the Git.Repo path is not changed. Probably it's fine because the renames happen last. But may be better to just figure out why |
It is slow because it shells out to git to check things... that said I'm worried about anything which is O(N^2) even if we made it much cheaper... I was worried about the situations you mentioned, but couldn't get it to fail in any cases. We could always force invalidation like the last bit of the patch does in any other places that updates the repo. What should we do here? I'd really like to see something like this merged just for the Zewo perf win. |
The initializer is: public init?(path: String) {
guard let realroot = try? realpath(path) else { return nil }
self.path = realroot
guard Path.join(path, ".git").isDirectory else { return nil }
} It seems like However I imagine this is safe since you identified the place where invalidation should happen. I worry about this sort of thing however. The slow part of all this is the HTTP. |
} | ||
|
||
extension PackagesDirectory: Fetcher { | ||
typealias T = Package | ||
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove whitespace :)
I'm going to go ahead and take this once it passes CI, if there is fallout then that is probably useful to identify and codify in test cases, and I really want to see the perf win land. |
@swift-ci please test and merge |
Linux failure is unrelated. |
This adds new delegate methods for "missing inputs" and "multiple producers for a single node" errors. These provide context to the client now instead of constructing strings. See <rdar://problem/34333034>
for a large project (Zewo).