What did you do?

The other case is where I know a qualified identifier refers to a package in the current module, imports still heads off to scan the module cache

It might make sense to kick off the two queries concurrently, i.e. current module and module cache, but the latter will take a long time to come back with ~5G of code

But I would expect the latter query to be cancelled when the former returns a match, which will be very fast.

On a machine with a large amount of code in $GOPATH/pkg/mod, the following script will roughly show the slow performance. I think this is representative of the general case; other specific examples which are harder to reproduce exactly, exhibit even worse behaviour but are, I think, the same class of problem.

What did you expect to see?

goimports taking next to no time at all, because there is a "match" within the current module.

I thinkimports needs prioritise its search according to module distance from the main module, falling back to the module cache as a last resort.

Furthermore, I don't think the query against the module cache should be kicked off until modules reachable from the main module (including standard library of course) have been evaluated. Reason being, with a large amount of code in the module cache, the processing and IO cost can be huge.

What did you see instead?

goimports taking a long time, ~10 seconds for some particularly bad cases. In gopls, if you are invoking imports via "format-on-save", which is a blocking operation, this is particularly painful.