I created a basic Vapor project and am using source-lsp with Visual Studio Code. I have noticed that the CPU usage for sourcekit-lsp is well over 100% and that it is very slow. I can't even do basic code completion. Sometime after letting it settles down I will be able to hover over symbol names and get documentation. This is great. But as soon as I start to type something as simple as "print()" is says that
'expression resolved to an unused function'. print is a builtin in swift function and I can't even get code completion on it and it says it is an error. Also as soon as I get this error every time I hover over a symbol that was working before I now get "Loading...". So currently SourceKit-lsp is unusable. Eventually it comes back and the "print" does work but I don't understand why it is taking so long.
I have Xcode 11.5 installed with swift version 5.2.4. the VSCode server path setting is '/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/sourcekit-lsp'
Well I have really tried to use SourceKit-LSP with VSCode but I find that it is almost unusable. I am running on macOS Catalina with Xcode 11.5. A lot of time I will start typing and code completion will not work. When I hover over any symbols it just says "Loading...". Eventually, sometimes in a minute or so it catches up. In the meantime the fans on my brand new MacBook Pro 13" laptop spin up and the CPU usage goes crazy.
Yes. This is true. But even after I build the project which should rebuild the indexes. I still have this problem. What I might do over the next few days is create a video that show this issue. What I don't understand is that as soon as I start adding logic to a class by maybe creating a new method or calling an already existing method in one of my imported packages it just starts to randomly stop working properly and just bogs down.
Is the performance-improving commit mentioned by @blangmuir more recent than swift 5.3.1? I'm using that swift version because it seems to be the most recent available in Arch Linux without having to build it myself, which I expect would take a long time. But I'm using the VS Code plugin from a much more recent checkout of sourcekit-lsp. It is painfully slow; it's nearly always quicker to type a symbol in full than wait for the completer.
The same version of sourcekit-lsp (5.3.1) has much better performance when used in vim, and VS Code's performance is adequate when editing Typescript, so I think the problem is specific to this Code plugin and probably caused by this issue.
Correct, the code-completion performance improvement is in 5.3.2 and later.
Could it be that vim is triggering code-completion less often than VSCode, specifically when you're typing base identifiers (ie. not after a ".")? The default config for VSCode does autocompletion as you type, whereas the default for vim itself is to only complete when you ask for it (though of course everything is configurable).
I don't know if VS Code can be configured to only perform LSP updates/requests at the end of an insert operation (after pressing Esc) when using the vim plugin. That would help somewhat, but I don't think it's the main cause of the problem, because it would affect Typescript too.
I am using version 5.3.2. I am also running under macOS Catalina. It is working much better. One thing I have noticed is that when I am getting errors from the vscode plugin when I try and edit a “.h” c file. I have file.
(Attachment libcurl.zip is missing)
(Attachment SourceKit Language server log.rtf is missing)
At some point, my project started to take an insane amount of time to compile, that it seemed unreasonable for its size. I have checked what takes it so long and found out that swift-frontend spends much time in type checking.
The solution is to not rely on type inference in swift as it is unstable and annotate every single variable manually. After I did, my build time decreased from minutes to seconds, it was a 4000x improvement, in fact!
So you have two options relly: don't use swift or don't use type inference. Pick one that is appropriate for you.
It wasn't necessary to annotate every variable manually to solve your issue. With the right compiler diagnostics turned on you could've seen exactly which statement were taking an abnormally long time to compile and fixed those rathe than manually marking every statement.
I was writing in xcode and diagnostic was turned on, but it didn't show me anything. The most useful thing that I got from it is 'swift frontend failed with non zero exit code' stuff. And I got solved it that way. I suppose, another approach to take is to start to annotate some of the code until the problem vanishes.
I meant that there are additional compiler warnings you can turn on to see which statements are taking too long to type check so you can add types only where needed.
