VSCode Slow with LSP

Many users reporting that language check with VSCode is very slow. I can confirm it on RPI3b and on Rock64.
I am wondering is the problem is not with LSP implementation only, but with how it is used in VSC.
I can see that for every character typed the LSP check is issued. This is queued for all characters entered.

Better it would be to do an delta check periodically e.g. every 15-30s.
Can somebody have a look of possibilities at VSCode to do so.

I believe there has been work in this area, so identifying the versions involved could be helpful.

Sadly no.
We didn’t make any progress further than opening some issues in different repositories.

The client configuration part is done here:

Maybe the workspace API can start a check on “save” instead of watching for every change.
Every change could be fine if the server part is runnig on the same machine, but is obviously critical in our case where the server part is running with the openHAB instance.

1 Like

Hi,

i have the same problems. I played a bit with a JS LSP a while ago so i know that there are two ways to transmit the changes:

  • incremental
  • full

Full always sends the complete changed file which causes a lot of traffic and a lot of parsing.

Incremental only sends the changed parts and the server side takes care of merging that into the initial opened file.

Vscode LSP docs explain it a bit better here:

From my vscode experience i know that you can not use both modes at the same time so the server needs to be configured to use incremental instead of full transmission.

I can not find your lsp code, so maybe you can point me to it, so i can have a look what you guys do in your LSP.

If I am not wrong, it’s this one: https://github.com/eclipse/smarthome/tree/master/bundles/model/org.eclipse.smarthome.model.lsp

Also for the client: https://github.com/openhab/openhab-vscode

latest thread on VS Code: openHAB VS Code Extension 0.3.5

Hi,

thanks for pointing that out. I just found it as well, just was not sure in the beginning as i thought it was somewhere in the openhab github.

Here is the thing i mean in lsp4j which is used by the smarthome lsp:

Will check if i can find the place where it should be set.

1 Like

It would be great if you can identify and propose (with a PR maybe) such enhancement !

Several people are having issues with the code validation using VS Code and LSP.

Its a bit hard to read the code as it uses parts from many different packages. I think the LSP Impl it uses is this one:

And there incremental is set already. I’m currently not at home so i can not play around with my setup, but maybe i will find some time over the weekend to investigate a bit more.

I also found this:

Maybe its somehow related…

1 Like

Hi again,

i just found one possible issue that slows down the LSP. The LSP seems to load the items from the rest API http://host:port/rest/items. So if the call to the rest api is slow, the LSP is also slow.

This thread helped me a bit out about this:

I also have the echo binding installed. So i made measurements… With 2 or 3 Items from my Echo i measured around 1.5-1.7s to load all the items from the rest api. When i removed the echo items it went down to 0.5s.

Then i tested both with vscode again and its much faster without the echo dot items.

So maybe its not a LSP issue but a problem with the REST api for some items.

There are several config options for the VSC extension:

  // Enables communication with Language Server Protocol - installed in openHAB as 'misc-lsp' add-on
  "openhab.lspEnabled": true

  // Takes completions from Language Server instead of REST API
  "openhab.restCompletions": true

  "openhab.useRestApi": true

Have you tried to play with these?
For example: disable REST API and use only LSP (lspEnabled=true & restCompletions=false)?
I am not 100% sure about the restCompletions since the description is misleading versus the name of the parameter :slight_smile:

Hey,

yes i played a bit. When useRestApi=false then its the same as LSP disabled. Only local stuff is taken into account.

There was no noticable difference between restCompletions=true or false. Timewise it looked the same to me, no idea what happens internally.

So from outside without further investigation it looks like it always uses the items from the REST api. But i will look into it a bit more in detail tomorrow, maybe i can make out the difference between restCompletions true/false…

1 Like

I had to restart vscode for settings to have any effect. It was indeed the REST api that slows down the auto completion. Here i explain it a bit more in detail:

There already has been an issue on this, but unfortunately it was closed. Hopefully Kuba will read it and maybe reopen it.

Hi all,

Just some information for those, who don’t follow the github repo that frequently.

Code completions are coming from the rest api in the current extension version.
This is one reason for the high loads, so it would be a solution/workaround to disable them temporary.

This can already be done with the following setting.
grafik

It has to be set to false.
Caution: The description over there is wrong!
We recognized that during our investigation.

I have already opened a (wip) pull request for some smaller changes/fixes, which will correct this description too.

Also thanks to @MHerbst and @Rangarid, who are currently helping out actively to get some progress for the urgent problems.
We made a big step forward with identifying some problem sources and had already some good discussion and ideas on how to solve some of them on mid term.

Hi @Dim, What is the name (and location) of the config file to make those changes?

C:\Users\<uname>\AppData\Roaming\Code\User\settings.json

Thanks, I think I misunderstood. This setting applies to the VSC running on the remote machine.
I was wondering if the VSC support can be turned off on the openhab installation side.
I am running openhab on a rpi3b, but I am not using VSC, so I wanted to turn it off.

check: Disabling / Binding to an IP the Language Server Protocol (LSP) service

maybe also: bundle:uninstall org.eclipse.lsp4j ?

1 Like

OK, here is what I did, and it seems to have removed the LSP:

  • Enter karaf console on rpi and type:
    • bundle:stop org.eclipse.lsp4j.jsonrpc
    • bundle:stop org.eclipse.lsp4j
    • bundle:uninstall org.eclipse.lsp4j.jsonrpc
    • bundle:uninstall org.eclipse.lsp4j
  • Exit karaf and restart rpi.

Thanks for your help!

1 Like

You are welcome.

That is the best solution for the VSC extension: uninstall it and remove LSP also :slight_smile: (I have done the same :smile:)

The one thing though I now see is the following error during startup:

2018-12-15 11:43:52.218 [ERROR] [org.eclipse.smarthome.model.lsp                   ] - FrameworkEvent ERROR - org.eclipse.smarthome.model.lsp
org.osgi.framework.BundleException: Could not resolve module: org.eclipse.smarthome.model.lsp [130]
  Unresolved requirement: Import-Package: org.eclipse.lsp4j.jsonrpc
	at org.eclipse.osgi.container.Module.start(Module.java:444) [?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1634) [?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1614) [?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1585) [?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1528) [?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) [?:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [?:?]

I’m not sure if that will create any problems down the road?