New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/tools/cmd/goimports: painfully slow when cold #20610
Comments
I don't use goimports, but I use godoc -http:6060 and when it starts it solves the same problem. It also used to start responding only after minutes. Once I installed a SSD disk instead of the old mechanical one, it slurps the same $GOPATH content in just a few seconds. Maybe you're in the same situation (?). |
When cold, what does How large are your $GOPATH(s) by file count and bytes? SSD or not? What type of filesystem? If you have lots of stuff in your GOPATH and a slow disk or filesystem, adding to the |
@bradfitz here's the output when I run in verbose more:
It's clearly spending all it's time on scanning the filesystem. And now that you mention it, my My desktop actually uses an SSD for |
By moving my |
goimports does try pretty hard to minimize disk I/O even for mechanical drives. I'm a little surprised by the dups I see in:
I don't recall seeing that before. Might be worth looking into. Maybe we need a "goimports -index" flag too to build an index ahead of time, so future goimports runs are faster. I'm going to reopen this for investigation (at some point). Help wanted. |
Change https://golang.org/cl/53470 mentions this issue: |
I think the dupes are because of vendoring. They are all third-party packages and I can create these kind of dupes by just creating both I don't think it's an option to not visit both copies, though, because we can't really know whether they're the same version. I'd be happy to work on the mentioned -index flag, if someone tells me its worth doing. Would also be happy to investigate whether something else would be worth doing, but I have an SSD and a small GOPATH :) |
The import path is ambiguous in the presence of vendoring (e.g. golang/go#20610) Change-Id: I22f372b233b8554e3d9210b383a7df7a6a0f3eee Reviewed-on: https://go-review.googlesource.com/53470 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
#22370 is somewhat related. I don't think there's much to do here other than the preindexing, which would be a big, complicated step. Closing; please comment if you disgree. |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?What operating system and processor architecture are you using (
go env
)?What did you do?
The very first time I run
goimports
(ie: "cold") on a file that has any third-party imports, it is painfully slow. (30-60s in most cases) The complexity of the file (ie: LOC and number of imports) seems to matter very little, if at all.After that initial run, it is blazing fast (<300ms) for every subsequent file.
What did you expect to see?
I don't get the impression that
goimports
runs slowly as a general rule, so I expect it to be much faster than what I get.What did you see instead?
That initial run is painful, especially because I use a text editor that runs
goimports
automatically on save. I end up needing to trigger some trivialgoimports
manually in a terminal in order for my text editor to not freeze up on each save.I have a lot of repos in my
$GOPATH
, but before I start blowing packages away I would like to see if there's something else I may have misconfigured or could try to address this.I only have this trouble on my linux desktop. I also develop on a mac laptop, but never have trouble with
goimports
there. (and I believe the size of$GOPATH
is comparable since I use both for work) It seems to be a linux-exclusive issue for me.The text was updated successfully, but these errors were encountered: