Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upcmd/go: speed up 'go run' by caching binaries #33468
Comments
This comment has been minimized.
This comment has been minimized.
Duplicate of #25416? Unfortunately, that issue was closed. |
This comment has been minimized.
This comment has been minimized.
@eliasnaur Be advised that your |
This comment has been minimized.
This comment has been minimized.
@theclapp oops! Thanks, fixed. |
This comment has been minimized.
This comment has been minimized.
#25416 seems like the same issue. The rationale for closing it was that we'd prefer not to cache linked binaries, since they take up a lot of space, and in the case of It might make sense to cache binaries if the cache eviction policy were more aggressive for binaries in particular. The cache would need to be a lot smarter though. |
This comment has been minimized.
This comment has been minimized.
Yeah, it seems like instead of caching In the particular case of Gio's gio command, I think it makes sense to |
This comment has been minimized.
This comment has been minimized.
The resolution from last time was #25416 (comment) (amplified in #25416 (comment)). |
This comment has been minimized.
This comment has been minimized.
Note that, even with binary caching, |
This comment has been minimized.
This comment has been minimized.
Note that one can always set |
This comment has been minimized.
This comment has been minimized.
I think that point also runs in the opposite direction, and more strongly: experienced Go users can easily translate a |
This comment has been minimized.
This comment has been minimized.
When working within a module in module mode, (Also note that this point is in direct tension with binary caching: checking for the latest version is an expensive operation. If we assume that |
This comment has been minimized.
This comment has been minimized.
What files and directories? The source files for gioui.org/cmd/gio and its dependencies are only stored in the cache, which is read-only and in a known state, right?
What can I tell Windows users? Now that I think about it, perhaps what I like most about "go run" is that it is a simple cross platform way to run Go binaries regardless of environment variables. A "go run" variant for running (cached) binaries from $GOBIN would suffice. I could program my way out of checking version mismatches between the gio tool and the gio packages. |
This comment has been minimized.
This comment has been minimized.
I don't think we've currently baked any assumptions about the pristineness of the module cache into the build-caching logic. You're right that we could, though. But we'd still have to at least check the |
This comment has been minimized.
This comment has been minimized.
You could give separate instructions for
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Ok, so if we drop the requirement of using the latest version, which I agree is a dubious choice anyway, and if we assume that for most actual uses of the The first I think this is interesting because as I argue in #33518 (comment), |
This comment has been minimized.
This comment has been minimized.
FWIW, the points described in this issue and #33518 were the main reasons behind creating https://github.com/myitcv/gobin. Also linking #30515 therefore, specifically this comment: #30515 (comment). The most recent discussion with @ianthehat on a golang-tools call was that "something like |
What did you do?
With GO111MODULE=on and the Android SDK and NDK set up, this is the one-liner for creating an Android .apk app file for a Gio program:
What did you expect to see?
go run
running nearly as fast as a pre-installed command, that isWhat did you see instead?
@mvdan filed an issue that pointed out that while convenient, the command above is slowed down by
go run
always re-linking gioui.org/cmd/gio.This issue is about caching the binary from
go run
so it achieves nearly the same speed for its second and subsequent runs as a pre-installed command.Some slowdown is expected because
go run
needs to know whether a cached version is the newest. I expect that delay to be minimal with a proper GOPROXY set.Gio issue #15 also points out that teaching users to use
go run
is bad, but I believe there are valid reasons to usego run
:go run
doesn't pollute a user's $GOBIN if they just wanted to test or demo a command from a README.go run
command to itsgo install
equivalent if they prefer.go run
the latest version is always used.gio
already exists on my system (I believe it is a Gnome tool).