Really slow startup time

zack-littke-smith-ai commented 7 months ago

What version of rules_go are you using?

0.41.0, but also tried 0.46.0 to no avail

What version of gazelle are you using?

0.33.0

What version of Bazel are you using?

6.1.0

Does this issue reproduce with the latest releases of all the above?

Tried for this repo, but did not try upgrading bazel nor gazelle

What operating system and processor architecture are you using?

Ubuntu 20.04, 12th Gen Intel Core i7-12700K x 20, 62.5GB memory

Any other potentially useful information about your toolchain?

We dont have a particularly large codebase, nor is much CPU/mem taken by any process during this startup.

My current vscode configuration:

  "go.toolsEnvVars": {
    "GOPACKAGESDRIVER": " ..."
  },
  "go.enableCodeLens": {
    "runtest": false
  },
  "go.languageServerFlags": [
    "-rpc.trace", // for more detailed debug logging
    "serve",
    "--debug=localhost:6060", // to investigate memory usage, see profiles
  ],
  "gopls": {
    "build.directoryFilters": [
      ...
    ],
    "ui.completion.usePlaceholders": true,
    "ui.semanticTokens": true,
    "ui.codelenses": {
      "gc_details": false,
      "regenerate_cgo": false,
      "generate": false,
      "test": false,
      "tidy": false,
      "upgrade_dependency": false,
      "vendor": false
    },
    "verboseOutput": true
  },
  "go.trace.server": "verbose",
  "go.useLanguageServer": true,
  "go.buildOnSave": "off",
  "go.lintOnSave": "off",
  "go.vetOnSave": "off",

What did you do?

Currently, when starting the language server we see it takes minutes, sometimes tens of minutes, to finish loading. Code suggestions are nonexistent during this time, and saving files takes absurdly long. Attaching files from the language server from vscode: server_logs.txt

What did you expect to see?

Much quicker startup time

What did you see instead?

Very slow startup time. Additionally, bazel is blocked by this startup, disallowing any other tasks.

Is there possibly any configuration I missed, or further debugging steps i can try?

astein91 commented 6 months ago

Having same issue - happy to provide repros as well.

fmeum commented 6 months ago

@astein91 Please do, that would be very helpful.

Cc @JamyDev

astein91 commented 6 months ago

Running bazel clean --expunge seemed to help a little, but in general I find the hang tends to happen when a gopackagesdriver process is being called. I logged the output from manually running it here if it's helpful: https://gist.github.com/astein91/90a8f2aa086c89e07f6701570d21d04b

JamyDev commented 6 months ago

Sometime since (roughly) Go 1.20, gopls started requesting ./... from the packages driver, meaning the entire project scope. If you have a large project or build, that would likely be the root cause for this.

2 options here:

Filter out any ./... queries as part of your bash script, meaning only stdlib would be returned (this will mean that indexing will only work by opening all relevant files as it has no project global scope)
When ./... is the query, in the bash script set GOPACKAGESDRIVER_BAZEL_QUERY_SCOPE=//your/sub/targets/..., this will reduce the scope of the global query, while still giving you the ability to open other files. You can also just set that globally, but that would limit the indexing scope to only that package.

zack-littke-smith-ai commented 5 months ago

We were resolved by adding --output_base to the arguments sent to GOPACKAGESDRIVER_BAZEL_FLAGS, which sped up the server significantly. Thanks!

bazelbuild / rules_go