Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upcmd/go: `go env GOMOD` is too slow for use in interactive commands #29382
Comments
This comment has been minimized.
This comment has been minimized.
The algorithm has changed before, and will likely change again (whenever the default behavior switches over). Probably it's better to make I'm a total novice with the Linux From
I get the following:
|
bcmills
added
ToolSpeed
GoCommand
labels
Dec 21, 2018
This comment has been minimized.
This comment has been minimized.
I agree that'd be better, and I know Brad was looking at lazy-loading this kind of stuff, but in general keeping init functions out of something as big as the main go command seems pretty difficult. Maybe a new command in $GOROOT/bin, |
This comment has been minimized.
This comment has been minimized.
The lazy-loading issue was #26775. |
This comment has been minimized.
This comment has been minimized.
Let's see how far we can get making |
This comment has been minimized.
This comment has been minimized.
I actually was thinking the same when I saw I agree with the sentiment that milliseconds matter for some tools, but given that |
This comment has been minimized.
This comment has been minimized.
gopherbot
commented
Dec 21, 2018
Change https://golang.org/cl/155540 mentions this issue: |
This comment has been minimized.
This comment has been minimized.
I had a stab at this and shaved a millisecond off on my machine (20%). The bigger offenders given by I wonder if packages like http and tls could reduce their init cost even further. If not, perhaps it does make sense to split I'm also a bit puzzled by how |
This comment has been minimized.
This comment has been minimized.
|
This comment has been minimized.
This comment has been minimized.
Interesting - but the Go benchmark is also executing the go binary at each iteration. Perhaps it's faster since it's loading the same binary over and over again. If anyone knows of a better way to write a benchmark for this, please let me know. Benchmarking a function directly, like the generated init function for the entire |
This comment has been minimized.
This comment has been minimized.
gopherbot
commented
Dec 30, 2018
Change https://golang.org/cl/155961 mentions this issue: |
This comment has been minimized.
This comment has been minimized.
gopherbot
commented
Dec 30, 2018
Change https://golang.org/cl/155962 mentions this issue: |
This comment has been minimized.
This comment has been minimized.
gopherbot
commented
Dec 30, 2018
Change https://golang.org/cl/155963 mentions this issue: |
This comment has been minimized.
This comment has been minimized.
I've found a few more ways to remove work from I think we should be able to fairly easily shave off some more from I'll stop with the CLs for now, to get some input on the benchmark and style of the CLs. Happy to work on more once these have been approved. |
This comment has been minimized.
This comment has been minimized.
Retitling to reflect the current approach. |
heschik commentedDec 21, 2018
We're porting a lot of tools to support modules, and most of them need to know whether modules are enabled to turn on the newer, slower, potentially buggier code path. Running
go env GOMOD
takes about 10ms, which is not negligible for an interactive command likegodef
orguru
. The algorithm for determining if modules are on is just simple enough to tempt people to roll their own. In fact, there's already a second implementation ingo/build
:go/src/go/build/build.go
Line 977 in 429bae7
This is unfortunate, especially since the algorithm changed in http://golang.org/cl/148517. (Maybe not in a way that matters for go/build? Not sure.)
I think it'd be helpful to have a standalone internal package that implemented this functionality that could be used for
go env
,go/build
, and copied into x/tools for other tools to use.@bcmills @jayconrod @ianthehat