I'm having issue with latest gopls(comsuming too much CPU and slow) so i need to stay with older version

Can you please explain more? The latest gopls should not be appreciably slower than v0.11.0. If you are observing this, it would really help us if you could share more of what you see. Are you working in an open-source project? What do you perceive as being slow? When do you notice the CPU?

I'm not working on an open source project, i rely on gopls to do auto formatting and auto complete, with version v0.12.3, when i save, it take about 10-15 seconds to complete the save. Up on save, a notice pop up saying: Saving xxx.go:Getting code actions from "Go"
also when i use an interface, waiting for the suggestion dropdown list, it takes even longer. Meantime i have a top running to see the usage, gopls sometimes take 500% of CPU or even go up to 1000%.
with v0.11.0, this won't happen, everything happens within a secode and CPU is not that high

@sff2578 what you describe is a bug, plain and simple. We want gopls@v0.12+ to perform approximately the same as v0.11.0, using much less memory (and in the future, we want it to perform better than v0.11.0 across the board).

I know of certain areas where we could reduce CPU in v0.12.x (#60926), but those would be say a 50% reduction in CPU while typing. I wasn't aware of any order-of-magnitude regressions. We would greatly appreciate it if you would work with us to help us understand the problems you are facing. This could help many other users.

To prevent auto-upgrade, you can use the following setting, but as mentioned above we hope that you will work with us to resolve your problems with v0.12.x:
https://github.com/golang/vscode-go/wiki/settings#gotoolsmanagementautoupdate

Can you please run the gopls stats -anon command using gopls@latest, and share your results? That will give us a sense of the size of your repo. The -anon flag should remove any output that could contain file paths, but please do inspect the json blob to make sure it is something you are comfortable sharing.

CC @adonovan, who can also help track down this regression.

Thanks for the pointer, it now works fine without upgrading gopls, here's the output of the gopls stats -anon command:

{
  "DirStats": {
    "Files": 706,
    "TestdataFiles": 0,
    "GoFiles": 606,
    "ModFiles": 1,
    "Dirs": 23
  },
  "GOARCH": "amd64",
  "GOOS": "linux",
  "GoVersion": "go1.18.10",
  "GoplsVersion": "v0.12.4",
  "InitialWorkspaceLoadDuration": "10.497067387s",
  "MemStats": {
    "HeapAlloc": 1640464000,
    "HeapInUse": 1990836224,
    "TotalAlloc": 4751304536
  },
  "WorkspaceStats": {
    "Files": {
      "Total": 7815,
      "Largest": 4950165,
      "Errs": 0
    },
    "Views": [
      {
        "GoCommandVersion": "go1.18.10",
        "AllPackages": {
          "Packages": 1073,
          "LargestPackage": 514,
          "CompiledGoFiles": 7880,
          "Modules": 176
        },
        "WorkspacePackages": {
          "Packages": 9,
          "LargestPackage": 505,
          "CompiledGoFiles": 673,
          "Modules": 1
        },
        "Diagnostics": 56
      }
    ]
  }
}

Thanks @sff2578, that's really useful.

I notice something about your workspace, which may contribute tot he problem. According to that stats command, you have a package with 505 files in it. There are certain aspects of our new implementation that may perform very poorly on such huge packages.

Are you often working in that package? Did you notice the performance problems more significantly when working in that package?

Thanks for the reply. i do heavily rely on this package, i use the interfaces and functions in this package a lot. i tried manually created a simple package, it is not hitting this issue

I just ran an ecosystem metrics query for large packages, and quickly found several with >500 files. For example, this one has 672: https://github.com/oracle/oci-go-sdk/blob/master/dataintegration/. I ran gopls v0.12 on it and observed that it was indeed slow, especially to save a file, though still quite usable. A CPU profile showed time spent in parsing, type-checking, and analysis, but not typerefs. (It also showed the usual exaggerated hotspot of filecache.gc because of macOS setitimer syscall skew. I need to try it again on Linux)

I'm going to repurpose this issue to track fixing performance with large packages.

I and my colleagues is experiencing the same problem. gopls v0.12.x is very slow when working on any large golang package. I and my colleagues switched to go pls v0.11.0 and solved this problem.

We have tested on MacOs and linux. gopls produces same behavior.

@findleyr here is my output of gopls stats -anon

{
  "DirStats": {
    "Files": 3668,
    "TestdataFiles": 0,
    "GoFiles": 491,
    "ModFiles": 1,
    "Dirs": 386
  },
  "GOARCH": "amd64",
  "GOOS": "linux",
  "GoVersion": "go1.20.5",
  "GoplsVersion": "v0.12.4",
  "InitialWorkspaceLoadDuration": "5.689082703s",
  "MemStats": {
    "HeapAlloc": 285930864,
    "HeapInUse": 391864320,
    "TotalAlloc": 5906972808
  },
  "WorkspaceStats": {
    "Files": {
      "Total": 7270,
      "Largest": 7677237,
      "Errs": 0
    },
    "Views": [
      {
        "GoCommandVersion": "go1.20.5",
        "AllPackages": {
          "Packages": 1415,
          "LargestPackage": 291,
          "CompiledGoFiles": 7535,
          "Modules": 269
        },
        "WorkspacePackages": {
          "Packages": 79,
          "LargestPackage": 67,
          "CompiledGoFiles": 624,
          "Modules": 1
        },
        "Diagnostics": 0
      }
    ]
  }
}

Change https://go.dev/cl/509558 mentions this issue: gopls/internal/regtest/bench: add an 'oracle' benchmark repo

Change https://go.dev/cl/511337 mentions this issue: gopls/internal/lsp/cache: cache recently parsed files

Change https://go.dev/cl/503440 mentions this issue: gopls/internal/lsp/cache: move purgeFuncBodies into the parse cache

@sff2578 @crclz we'd love it if you'd try the v0.13.0 prerelease, and let us know if it improves things for you.

go install golang.org/x/tools/gopls@v0.13.0-pre.1

Also, do any of you have "staticcheck" enabled? We have observed that this can cause significant slowdown on v0.12.x vs v0.11.0.

Thanks.

We believe this is largely mitigated, based on our own benchmarking. If this is not the case for your repos, please comment with more information.

@findleyr Thank you for the new version of gopls! Comparing with v0.12.2, the speed of code formatting of v0.13.0 is largely optimized.
However, when editing a large go package, the intellisense speed of v0.13.0 is still slower than v0.11.0 (roughly ~500ms vs <100ms), which is quite significant (at least for me). I hope the intellisense speed also could be optimized.

@crclz that's a surprising difference, which is unexpected. Out of curiosity, does this reproduce when only a single file is open (there are reasons why intellisense may be slower with many files open).

It would be helpful if we could dig into this more, grabbing a profile.

@findleyr Only a single file is open. I have recorded my screen, wish it could help.

v0.13.0:

v0.11.0:

Re-opening due to above report of slow completion in large packages.

I suspect this may be a result of our change to the meaning of "completionBudget": previously, we would start the timer before type checking, now we start it after (and we ensure that the depth=0 pass completes).

In that case, I think the fix here is to support streaming completion results, which will significantly reduce the perceived latency. Then we don't have to care so much about e.g. how many unimported completion items we compute.

Change https://go.dev/cl/516678 mentions this issue: gopls/internal/regtest/bench: add an oracle completion benchmark

Change https://go.dev/cl/511435 mentions this issue: gopls/internal/lsp: avoid duplicate type checking following invalidation

@sff2578 I'm having trouble reproducing the behavior you observe, even in very large packages. However, I have theories.

I'm curious if the CL above improves completion performance for you. If you don't mind, could you test it out?

git clone https://go.googlesource.com/tools
cd tools/gopls
git fetch https://go.googlesource.com/tools refs/changes/35/511435/2 && git checkout FETCH_HEAD
go install

That should significantly reduce CPU during autocompletion in large packages, but doesn't have a large impact on latency for me. It may be different on your computer, if you have less processing available.

Could you also try reducing your completion budget, setting "completionBudget": "10ms", to see if that has an effect?

Thanks.

@findleyr sorry was busy recently, i experienced the same thing as @crclz mentioned, i'll try the steps you provided and share the result when i have time

In that case, I think the fix here is to support streaming completion results, which will significantly reduce the perceived latency.

BTW, unfortunately streaming support is not available in VS Code: microsoft/vscode#105870. We could perhaps add it for other clients, but it's harder to justify the engineering effort if not available in VS Code.

@sff2578 and @crclz, have you had any luck testing that patch? I'm very curious if it helped.

@findleyr I was a little busy on weekdays, and I will test it on weekends. And I realized that optimizing the performance requires a code repo that can reproduce the high completion time. Sharing code is forbidden by my company, so I am also trying to create a sharable repo from my company's repo.

No worries. I'm trying to decide whether to land this CL in gopls@v0.13.2. If you can determine whether it helps your use-case, it will help me decide. If you could test it this weekend, that would be great.

I don't think it's necessary to create a sharable repo. We have other repos to test on, and this CL helps there. If it doesn't help you, we'll figure out why and find a public repo that has the same behavior.

Thanks.

@findleyr I did some test just now and had some conclusion:

• v0.11.0 has the best completion speed
• Patch could slightly increase the speed
• Adding ui.completion.completionBudget: 10ms could significantly increase the speed, but the speed is still slower than v0.11.0

Here is the experiment record:

More information is written in this document: https://bytedance.feishu.cn/docx/H8X3dQpfYovJdbxXkZLcQnOQnlf