VSCode Slow with LSP

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?

I doubt it
I tried to find a way to completely disable LSP on OH2 but I couldn’t find any.
Maybe we need to open up an issue to request this functionality (an option to disable completely LSP)

try to remove also: bundle:uninstall org.eclipse.smarthome.model.lsp

Hey guys,

Sorry to hear that vscode/lsp doesn’t fit your needs and you don’t want to use it,
but that’s of course your decision and you are free to do so.

Anyway it would be nice if you could keep this thread a bit cleaner.
“How to disable LSP” i not the topic and it seems that there was already a thread which is better for discussions about your problem/solution.

I think there are enough others that still want to us vscode/lsp and want to be informed about the current problems, which includes reading this thread too.

Sorry @Confectrician, did not mean to derail the discussion thread here :wink:
I am sure that LSP is great for a addition for a lot of users, and I do not want to discourage anybody from using it. Every use case is different.

1 Like