3 ms·

I don't get it. The number of dependencies is constant. Which means that both of them need to make approximately the same amount of network requests. Where d

I don't get it. The number of dependencies is constant. Which means that both of them need to make approximately the same amount of network requests. Where does the I/O difference come from then? Also, since you've mentioned Cargo. Its slowness actually used to be one of the main pain points about which the Rust people at one of the companies I've worked for in the past complained a lot during the water cooler discussions. Granted, that was a couple of years ago, and Cargo has probably made progress since then.

pcwalton 7y ago
As I recall, dep had to parse Go code over and over during the dependency resolution process instead of caching it. And any cargo slowness is likely the fault of rustc or I/O. It's received a lot of profiling work and the core dependency solver has never been a performance issue to my knowledge.
- steveklabnik 7y ago
  It would seem this is correct. From the docs: https://github.com/golang/dep/blob/master/docs/FAQ.md#why-is-dep-slow https://github.com/golang/dep/blob/master/docs/FAQ.md#why-is... There are two things that really slow dep down. One is unavoidable; for the other, we have a plan. The unavoidable part is the initial clone. ... Fortunately, this is just an initial clone - pay it once, and you're done. The other part is the work of retrieving information about dependencies. There are three parts to this: * Getting an up-to-date list of versions from the upstream source * Reading the Gopkg.toml for a particular version out of the local cache * Parsing the tree of packages for import statements at a particular version The first requires one or more network calls; the second two usually mean something like a git checkout, and the third is a filesystem walk, plus loading and parsing .go files. All of these are expensive operations. ---------------- For context, in comparison, Cargo has the same #1 problem. But for #2, the information on all dependencies is stored in the index itself; this means that Cargo can figure out what dependencies you need without any network calls at all, let alone downloading, git checkout, and filesystem walk. I do not know how go mod compares, off the top of my head.
  - deleted 7y ago
    [deleted]

pcwalton 7y ago

As I recall, dep had to parse Go code over and over during the dependency resolution process instead of caching it. And any cargo slowness is likely the fault of rustc or I/O. It's received a lot of profiling work and the core dependency solver has never been a performance issue to my knowledge.

steveklabnik 7y ago
It would seem this is correct. From the docs: https://github.com/golang/dep/blob/master/docs/FAQ.md#why-is-dep-slow https://github.com/golang/dep/blob/master/docs/FAQ.md#why-is... There are two things that really slow dep down. One is unavoidable; for the other, we have a plan. The unavoidable part is the initial clone. ... Fortunately, this is just an initial clone - pay it once, and you're done. The other part is the work of retrieving information about dependencies. There are three parts to this: * Getting an up-to-date list of versions from the upstream source * Reading the Gopkg.toml for a particular version out of the local cache * Parsing the tree of packages for import statements at a particular version The first requires one or more network calls; the second two usually mean something like a git checkout, and the third is a filesystem walk, plus loading and parsing .go files. All of these are expensive operations. ---------------- For context, in comparison, Cargo has the same #1 problem. But for #2, the information on all dependencies is stored in the index itself; this means that Cargo can figure out what dependencies you need without any network calls at all, let alone downloading, git checkout, and filesystem walk. I do not know how go mod compares, off the top of my head.
- deleted 7y ago
  [deleted]