Skip to content
This repository has been archived by the owner on Oct 12, 2022. It is now read-only.

Take 3s to go to definition for symbol of internal package #323

Open
anphung opened this issue Oct 5, 2018 · 9 comments
Open

Take 3s to go to definition for symbol of internal package #323

anphung opened this issue Oct 5, 2018 · 9 comments

Comments

@anphung
Copy link

anphung commented Oct 5, 2018

In vscode:
For symbol of internal package (the package that I'm coding), it takes 3s to jumps to the definition.
For symbol of external packages (packages that are in vendor) , it jumps nearly instantly.

macOS High Sierra 10.13.16

$ go-langserver -version
v3-dev
$ code --version
1.27.2
f46c4c469d6e6d8c46f268d1553c5dc4b475840f
x64
@keegancsmith
Copy link
Member

Can you include your go config for vscode? Any diagnostic output to help diagnose? Is this in OSS, so I can try reproduce?

@anphung
Copy link
Author

anphung commented Oct 9, 2018

Here is my go config

  "go.docsTool": "gogetdoc",
  "go.languageServerExperimentalFeatures": {
    "autoComplete": true,
  },
  "go.languageServerFlags": [
    "-diagnostics",
  ],
  "go.useLanguageServer": true,

go-langserver output:

langserver-go: reading on stdin, writing on stdout
Passing an initialize rootPath URI ("file:///Users/anphung/go/src/github.com/anphung/mypackage") is deprecated. Use rootUri instead.

If sub package (e.g.: github.com/anphung/mypackage/controller) inside mypackage contains small number of files (around ~20 files), It jumps fast.
If sub package contains big number of files (> 150 files, each file has 10 definitions), it jumps slow.
I guess that's the limit.

Sorry, It's not OSS.

@keegancsmith
Copy link
Member

If you remove the -diagnostics flag is it faster?

@anphung
Copy link
Author

anphung commented Oct 9, 2018

It was running slow without it. tried to add it to see if there is some info, but no info.

@keegancsmith
Copy link
Member

Thanks for the information. This should still be fast regardless. I'll check if we have regressed on which j2d engine we use with your flags (we have a slower one which is more correct, but by default we should be using a godef based j2d).

@anphung
Copy link
Author

anphung commented Oct 9, 2018

Thanks for checking :)

@keegancsmith
Copy link
Member

We haven't regressed here. I'm unsure how deep you want to get into this, but a pprof profile of what its doing to take that long would be amazing. https://github.com/sourcegraph/go-langserver#profiling

@anphung
Copy link
Author

anphung commented Oct 12, 2018

Here we go.

"go.languageServerExperimentalFeatures": {
    // "autoComplete": true,
  },
  "go.languageServerFlags": [
    "-pprof",
    "localhost:6060",
  ],
  "go.useLanguageServer": true,
  1. Click on a symbol in vscode
  2. Immediately go to terminal and run the go tool pprof...

pprof.zip

@anphung
Copy link
Author

anphung commented Oct 12, 2018

Ah, it's like this, try to jump to Definition of:

  1. definitionGodef
    https://github.com/sourcegraph/go-langserver/blob/master/langserver/definition.go#L25
    and
  2. Location
    https://github.com/sourcegraph/go-langserver/blob/master/langserver/definition.go#L29

Location got jumped into immediately, definitionGodef has a little delay.
Maybe it's because package github.com/sourcegraph/go-langserver/langserver is more complex than package github.com/sourcegraph/go-langserver/pkg/lsp.

I guess if a package (excluding children package) is to big, it'll be slow because of i/o bottle neck.
So, it's not about internal vs. external package.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants