/cc @heschik

Please include a log.

@heschik I haven't managed to pin down the circumstances that lead to the worst case performance, but this is a run after a machine boot:

gopls.log

Notice the call took ~17s.

My recollection/expectation (based on previous discussions about this) is that this call should never be blocking on a refresh of the goimports cache. Rather it should use the current state of the cache, and that cache should be refreshed periodically.

Sorry, I don't understand. There are no completion requests in that log; what took 17s?

There are no completion requests in that log

We're not talking about completion here, rather a code action call:

[Trace - 08:48:32.191 AM] Sending request 'textDocument/codeAction - (2)'.
Params: {"textDocument":{"uri":"file:///home/myitcv/dev/learn.go.dev/gitea/cmd/gitea/main_test.go"},"range":{"start":{"line":0,"character":0},"end":{"line":0,"character":0}},"context":{"diagnostics":null}}


[Trace - 08:48:49.498 AM] Received response 'textDocument/codeAction - (2)' in 17306ms.

Oh, right, sorry. Churning through email too quickly.

What you're saying about not blocking is only for autocomplete. It doesn't apply to imports on save, which is essentially a call to the goimports command line. Unlike autocomplete, imports on save is not a best effort call; it takes as long as it takes to get an answer. If the cache is cold, because you haven't done any autocompletes yet or whatever, then it may indeed be quite slow. 17 seconds seems unreasonable but 3 is in line with what we see from Macs.

I suspect you will see the exact same behavior with the goimports command line after a reboot. You can pass -v and show a log if you like, but most likely this is just going to boil down to Macs being bad at filesystems as usual.

What you're saying about not blocking is only for autocomplete

Interesting. This must be a combination of my misremembering and an unfortunate (pathological) refactor which triggered this wide search.

17 seconds seems unreasonable but 3 is in line with what we see from Macs

This is on Linux FWIW.

Thanks for the response. I'll close this as working as intended, unless you think there's mileage in making imports on save best efforts?

I think that's explicitly not what users want; if you hit save you expect your imports to show up, not for it to silently give up after a second or two. Obviously faster would be better.

If it's Linux on an SSD this is somewhat more surprising. I would be curious to see a goimports -v run, but it's unlikely there's going to be much to do. A single-character "import" is a pathological worst case for goimports since it has to fully parse every package with that letter in the name looking for exports.

Anecdotally, before gopls I don't remember having slow goimports in my project. With gopls it often takes seconds when I save. (Note that my save hook does imports and formatting, and I'm not 100% sure it is imports). There are other vectors of slowness such as gopls computing other code actions beyond just imports, or perhaps gopls deciding it needs to run a "go list" or what not before it gets into the imports code.

I agree that there are many possible causes but in this case Paul has privately shared a goimports run that is exactly as slow as gopls, so here it's just the nonspecific search over a large module cache. I don't think there's anything in particular to do, unfortunately. Perhaps refuse to search for single-letter imports, but I'm sure that would annoy someone.

@heschik: Is this OK to close?

Unless we're prepared to compromise on something, I don't have any ideas to improve the situation. So yeah.