Hi, thanks for the report.

There are two possibilities for what is going on here: one is that gopls RPCs are getting queued up behind a slow request, and another is that your CPU sufficiently saturated to make everything slow. Based on your description of the symptoms, this sounds like the first scenario. In this case, RPC logs would be very helpful. Would you mind grabbing some logs and attaching them here? Instructions for how to do so can be found here.

I have attached a very basic GTK program that uses github.com/gotk3/gotk3

FWIW I don't see any attached program, but in any case the logs would be most useful.

FWIW I don't see any attached program

GitHub won't let me attach a .go file, and Firefox crashed while I was appending it as a code section and I forgot to update the issue... Here is one of GoTK3's examples that should reproduce the issue.

I'll work on getting logs.

I generated gopls.log.zip using the following settings:

    "go.languageServerFlags": [
        "-logfile", "REDACTED/Desktop/gopls.log",
        "-rpc.trace"
    ],

    "gopls": {
        "env": {
            "GOCACHE": "/tmp/go-build-cache",
        }
    },

As soon as I do something to trigger an RPC to gopls (such as opening simple.go which makes a request for code lenses), a horde of C compiler processes are spawned. These processes certainly consume a lot of power, but that didn't have a noticeable impact on my overall system performance. Once cc1 no longer appears in top, editor features driven by gopls start working again.

FWIW, I'm using Gentoo with USE=-bindist, meaning everything (non-proprietary) is compiled locally from source. So it's conceivable that go install github.com/gotk3/gotk3-examples/gtk-examples/simple performs especially badly with this setup, maybe because it's recompiling all the C library dependencies (gtk, gdk, glib, opengl, etc).

I experience the same problem using github.com/gotk3/gotk3 with neovim + gopls. Everytime I jump to a definition related to gotk3, gopls triggers cgo compilation, which is very slow and cpu intensive.

Here is one of GoTK3's examples that should reproduce the issue.

Thanks, I'll experiment with that.

As soon as I do something to trigger an RPC to gopls (such as opening simple.go which makes a request for code lenses), a horde of C compiler processes are spawned.

Discussed this a bit with the team as I don't have that much experience with cgo. Yes, this is almost certainly related to cgo, apparently invoked during go list, which would explain the symptoms you describe.

Everytime I jump to a definition related to gotk3, gopls triggers cgo compilation, which is very slow and cpu intensive.

Hmm, I don't yet understand why this would be the case. I'll look into it.

Yeah, this is a pretty poor experience. I think it might be improved by @stamblerre's work on metadata invalidation, which should be in soon.

@echovl which neovim client are you using? I'm guessing the reason you hit a recompilation is that you jumped outside of your workspace, which at least on coc.nvim will trigger a new workspace folder in your session. It should only happen on the first jump, although the build takes so long that may be enough...

I think the best we can do here is to not become unresponsive after the initial workspace load, which means most gopls behavior continues to work in the presence of stale package metadata (even if a load is ongoing). I'm not 100% sure this will be possible, but @stamblerre's pending changes get us at least part of the way there.

Putting this in gopls/v0.7.1, as investigating this is timely.

Yes I did notice that, after the first jump everything is responsive again, thanks for your help! @findleyr