dep status runs significantly slower in a docker container on a mac

[jaloren]

I am actually not sure whether this is a bug in dep or a combination of a behavior in dep interacting badly with docker. Running dep status takes 3 seconds on my mac and over 96 seconds in a docker container. The code, including the vendor directory, are identical in both scenarios.

I am running docker on my mac. I have a go package that i build on my mac using go 1.9.2. I also build this go package in a linux docker container on my system. The vendor directory is part of my vcs so the vendor folder is the same in both contexts. I am also using the same version of dep on both my mac and inside the docker container.

The only obvious difference here is that the docker container is a linux filesystem running on top of a linux vm which is in turn running on top of a xhyve hypervisor. But I don't understand why that should have such a severe impact on the performance of dep status, especially since the vendor directory has not changed.

What version of dep are you using (dep version)?

v0.4.1-32-g235ce96c

What dep command did you run?

I ran dep status.

time dep status -v
Collecting project constraints:
(1/10) github.com/Microsoft/go-winio
(2/10) github.com/docker/distribution
(3/10) github.com/docker/docker
(4/10) github.com/docker/go-connections
(5/10) github.com/docker/go-units
(6/10) github.com/opencontainers/runc
(7/10) github.com/pkg/errors
(8/10) golang.org/x/net
(9/10) golang.org/x/sys
(10/10) gopkg.in/yaml.v2
Checking upstream projects:
(1/10) github.com/Microsoft/go-winio
(2/10) github.com/docker/distribution
(3/10) github.com/docker/docker
(4/10) github.com/docker/go-connections
(5/10) github.com/docker/go-units
(6/10) github.com/opencontainers/runc
(7/10) github.com/pkg/errors
(8/10) golang.org/x/net
(9/10) golang.org/x/sys
(10/10) gopkg.in/yaml.v2

PROJECT                           CONSTRAINT     VERSION        REVISION  LATEST   PKGS USED
github.com/Microsoft/go-winio     v0.4.7         v0.4.7         7da180e   v0.4.7   1   
github.com/docker/distribution    v2.6.2         v2.6.2         48294d9   v2.6.2   2   
github.com/docker/docker          ^1.13.1        v1.13.1        092cba3   v1.13.1  19  
github.com/docker/go-connections  v0.3.0         v0.3.0         3ede32e   v0.3.0   3   
github.com/docker/go-units        v0.3.2         v0.3.2         0dadbb0   v0.3.2   1   
github.com/opencontainers/runc    v0.1.1         v0.1.1         baf6536   v0.1.1   1   
github.com/pkg/errors             v0.8.0         v0.8.0         645ef00   v0.8.0   1   
golang.org/x/net                  branch master  branch master  5ccada7   2fb46b1  3   
golang.org/x/sys                  branch master  branch master  af50095   37707fd  1   
gopkg.in/yaml.v2                  branch v2      branch v2      d670f94   d670f94  1 

What did you expect to see?

The command would complete in a few seconds in a docker container.

What did you see instead?

The command completed in over 96 seconds or longer in the docker container.

[carolynvs]

I am guessing that the difference is actually the dep cache in GOPATH/pkg/dep and if you run the dep status command twice in the container, the first command will be slow while populating the cache and the second call will be more what you expect.

In our FAQ for CI, one option is to preserve the cache directory. What I've seen people do on their local machine is to mount a directory into the container under GOPATH/pkg/dep so that the cache persists between docker runs.

[jaloren]

@carolynvs yes mounting the dep pkg dir in the container significantly improved performance. Thanks for the tip.

The actual issue I was investigating was whether our jenkins CI would run dep status to verify that package dependencies are in a good state before building. For a variety of reasons, we won't be able to take advantage of the pkg cache during our CI builds. Given how severe the latency is for just 10 packages, its probably not tenable for us to do that in our CI pipeline (time is money or something to that effect) especially since i would expect the latency to increase as the dependency graph grows. Not the end of the world though. Since we put our vendor directory in VCS, we'll just skip dep status.

My experience with dep is quite positive over all but the latency is so severe that I don't know how anyone could use this tool effectively if they did not put their vendor directory in VCS. Basically, we treat dep as a "run only as needed" operation and then commit changes including vendored deps into git. Worse case scenario someone might loose 30 minutes every couple of weeks.

So I am actually not sure if this counts as a bug. Feature enhancement maybe? Or maybe close it as a dup of all the other performance improvement work being done?

[jmank88]

So I am actually not sure if this counts as a bug. Feature enhancement maybe? Or maybe close it as a dup of all the other performance improvement work being done?

Related performance Issues/PRs: #431, #415, #1250

[carolynvs]

Basically, we treat dep as a "run only as needed" operation and then commit changes including vendored deps into git.

That is how I use dep, and I don't even have the network as an excuse. It just makes my life easier. 😉

Since there isn't a clear ask, and we have existing issues for improving performance I am going to close this issue. Please leave a comment to reopen if things change!