Closed SOF3 closed 3 months ago
We run go mod edit -json
from each directory to be formatted to figure out what Go module each Go package belongs to. That is what you are seeing above; this is not related to us running gofmt
in any way.
Indeed this appears to be a problem with your asdf setup; it appears to just make running go
much slower. I'm not sure what kind of fix you expect gofumpt to do here; there is no Go API to figure out what module a package belongs to. That information is only available through executing cmd/go.
I had been suffering with this issue for almost two years (I used to think it was some weird OS/machine problem) and I only lately discovered the cause here by accident (refactoring the project setup to use go run gofumpt
instead of $PATH/gofumpt
) and noticed the sudden improvement in performance, in which case I started trying to figure out the difference and noticed the different $PATH.
I am reporting this issue mainly to help others discover this cause more easily. I don't really know what could possibly be done about it (I guess the only reaiistic "fix" is to make asdf shims faster or warn if it is invoked at high frequency?)
My only advice would be to stop using Go version wrappers like asdf :) More often than not they will be rather slow, especially when running tools on top of them, as they will often need to invoke go
multiple times in sequence. I'm fairly sure gopls
would have a very similar issue.
Go these days has a way to manage versions itself - see https://go.dev/doc/toolchain. It does add a bit of overhead, but it's cached, so in the fast path it barely adds any overhead; I seem to recall it was under a few milliseconds.
Beacuse wrappers like asdf are meant to be transparent, there's really not much that gofumpt can do. Raising an issue there sounds like a good idea, although I'm not sure what would be the best solution there other than just making the wrapper fast enough that it isn't noticeable, like GOTOOLCHAIN.
When I run
go run mvdan.cc/gofumpt -d .
, it takes 1.4s for my project, but if I dogo build mvdan.cc/gofumpt -o gofumpt
instead,./gofumpt -d .
takes 24s to run, and 70% oftime
is system time.After some debugging, it turns out that it is becomes I installed Go with asdf, and the
go
command resolves to~/.asdf/shims/go
by default, but when I dogo run
, the installed Go version is added to my $PATH and executing Go will call the native Go binary directly. This is proved by the test that runningPATH=~/.asdf/installs/golang/1.20/go/bin:$PATH ./gofumpt -d .
only takes around 1.4s (i.e. adding the direct links togo
andgofmt
to my PATH is the factor that causes the 20x slowdown).I don't know how gofumpt works, but I can see evidnce of invoking Go when I run
strace
:You may argue that this is an asdf issue rather than a Go issue, but it would be great if gofumpt could invoke gofmt through calling the Go package directly rather than depending on the operating system.