Why gobin takes extra ~0.5 sec to run cached binary

[powerman]

Actually if we consider user+sys on single-core CPU it takes up to about extra 2 seconds!

$ time gobin -run github.com/golangci/golangci-lint/cmd/golangci-lint@v1.31.0 --version
golangci-lint has version v1.31.0 built from (unknown, mod sum: "h1:+m9I3LEmxXLpymkXRPkDQGzOVBmBYm16UtDiXqZxWek=") on (unknown)

0.484 real  1.469 user  0.350 sys  46MB RAM
$ time gobin -m -run github.com/golangci/golangci-lint/cmd/golangci-lint --version
golangci-lint has version v1.31.0 built from (unknown, mod sum: "h1:+m9I3LEmxXLpymkXRPkDQGzOVBmBYm16UtDiXqZxWek=") on (unknown)

0.473 real  1.280 user  0.363 sys  50MB RAM
$ time .gobincache/github.com/golangci/golangci-lint/@v/v1.31.0/cmd/golangci-lint/golangci-lint --version
golangci-lint has version v1.31.0 built from (unknown, mod sum: "h1:+m9I3LEmxXLpymkXRPkDQGzOVBmBYm16UtDiXqZxWek=") on (unknown)

0.062 real  0.071 user  0.016 sys  38MB RAM

[myitcv]

gobin essentially works in much the same way as go install works: if the target binary (within the gobin cache) exists, it checks whether any work is required to update it. That requires looking at the source files that go into building it. This ends up being a relatively fast operation compared to compiling and especially linking, but there is a cost nonetheless. And that is the cost you are seeing. If you ran go install with the target file in place you would like see similar cost.

There are optimisations to be had here, but to be clear nobody is actively working on gobin as of now.

I'll close this as the issue is effectively covered by #59

[powerman]

nobody is actively working on gobin as of now

Sorry for offtopic, but is this because of gobin considered a dead end and some other replacement is available/coming, or for any other reasons (e.g. lack of time, work good enough as is, etc.)?

[myitcv]

Good question: I should have elaborated on that.

For me personally, it's mainly a lack of time, combined with the fact that what is there is sort of good enough. That said, we would absolutely consider bug fixes.

In Go 1.16 there is support for go install $pkg@$version to perform a global install. That handles part of the use case of gobin.

In terms of current discussion there is golang/go#42088, and on the last golang-tools there was discussion about splitting off another issue that discusses go run in the context of a module (because the conditions are somewhat different).