[LSP] OpenHAB java process high CPU consumption VSCode

[Moxified]

I'm noticing very high (100% of both cores) cpu utilization on the OH java process while editing rules via VSCode. If you launch OH then VSCode, start a fresh rules file, it isn't bad for a while until you get more and more in there. After a while you can watch the syntax checking drag far behind. Eventually it will catch up if you stop typing. It can take a long time though and immediately pegs when you start typing.

It doesn't appear to matter the types of rules. I have 4 different rules files that I have been copying rule blocks in one at a time from my production OH instance on 2.1. All 4 files suffered the same fate once I got over 50 or so lines.

Interestingly, I find that if you launch VSCode and then restart OH while VSCode is still open, the problem goes away.

OH Hardware is a XenServer VM with 2x2.0ghz cpu and 2GB ram Debian 9.3 java version "1.8.0_131" Java(TM) SE Runtime Environment (build 1.8.0_131-b11) Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode) OH 2.2.0 build 1140

VSCode version 1.19.0 running on macOS 10.13.1

[Moxified]

Any help on this? Makes LSP useless. Worse yet, I'm finding that I have to restart OH on most occasions now to get the cpu to drop to normal.

[triller-telekom]

@Moxified I have just tried to reproduce your problem but failed to do so. Could you please try to install the latest OH snapshot to see if your problem still persists?

I have a rules file with >160 lines now and you said your problem starts at 50 lines.

If your problem still persists on the latest OH snapshot, please post a rule file together with the relevant items.

Otherwise please close this issue. Thank you!

[Moxified]

Hello @triller-telekom

I just updated my snapshot testing machine to the latest and retested... yes, the issue still persists. I took a screen grab of it happening. I just noticed you are asking for the rules file. I'll have to look at the file and see how sanitary it is. I dislike sharing things related to my automation for security reasons. I have 3 different debian OH servers for testing purposes and they all have the same issue so it is either something to do with Debian, the way I install it or? but it isn't just one box.

Video: https://youtu.be/ypPaTKrlpoU

This particular file had 564 lines. The 50 I think was more when it started really bogging down and not necessarily a hard number. I'll do some more testing if I have time... perhaps I can start a new rules file that is clean that I can share.

Notes on the video:

You can see that a simple enter causes spikes for a few seconds. auto complete/suggesting is painfully useless due to lag. pasting large quantity of text (end of video) didn't seem to cause the issue interestingly. moving around quickly in the large pasted text yielded reasonable performance even when adding a simple space.

Notes on hardware: server: 2.0 dual core with 2gb memory debian 9 fully patched today. Only running OH, nginx and mysql for OH purposes. Samba share for OH files. Machine is a VM, host is xenserver and mostly idle.

java version "1.8.0_131" Java(TM) SE Runtime Environment (build 1.8.0_131-b11) Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

Workstation: macbook air over wireless, unrouted to samba share. vscode 1.22.2 with OH 0.3.5 extension.

[sihui62]

Meanwhile more users are experiencing similar issues when using Visual Studio Code. The autocompletion and syntax checking is extremely slow, if not unusable.

https://community.openhab.org/t/vs-code-openhab-extension/30205/244 https://community.openhab.org/t/vs-code-openhab-extension/30205/248 (video) https://community.openhab.org/t/vs-code-openhab-extension/30205/245

[Confectrician]

Another one for the record: https://community.openhab.org/t/running-vs-code-slows-down-openhab/46652

[airix1]

I am experiencing this as well. As soon as I use VS and it connects to the lsp server, OH essentially hangs:

Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.CommunicationManager@1e74987' takes more than 5000ms. Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@ad25df' takes more than 5000ms. Dispatching event to subscriber 'org.openhab.core.events.internal.EventBridge@1b3fcf4' takes more than 5000ms. Fatal transport error: java.util.concurrent.TimeoutException

Code validation no longer works at this point. Restarting OH while VS is running works for me as well for a while but then it hangs again.

[dvehof]

Is this issue still in progress? I got the same issue, very annoying since autocompletion and and syntax checking is unusable for me :(.
If there is any missing info I can grab in my setup or anything I can test, let me know!

Thanks!

[SamuelBrucksch]

I experience the same issue. Here are also more user from openhab that experience issues: https://community.openhab.org/t/vscode-slow-with-lsp/54802

[SamuelBrucksch]

Meanwhile more users are experiencing similar issues when using Visual Studio Code. The autocompletion and syntax checking is extremely slow, if not unusable.

https://community.openhab.org/t/vs-code-openhab-extension/30205/244 https://community.openhab.org/t/vs-code-openhab-extension/30205/248 (video) https://community.openhab.org/t/vs-code-openhab-extension/30205/245

I just noticed that slow autocompletion is not because of problems in LSP. The vscode Plugin takes the items from the openhab rest API http://openhab/rest/items, if that request is slow, then the autocompletion is as well. I noticed that amazon echo control for example slows down the rest api quite a bit. With 3 items from amazon echo control binding the items request took 1.5s, without them around 0.5s. This also influences the speed of the autocompletion. But this is not LSP related.

[airix1]

Meanwhile more users are experiencing similar issues when using Visual Studio Code. The autocompletion and syntax checking is extremely slow, if not unusable. https://community.openhab.org/t/vs-code-openhab-extension/30205/244 https://community.openhab.org/t/vs-code-openhab-extension/30205/248 (video) https://community.openhab.org/t/vs-code-openhab-extension/30205/245

I just noticed that slow autocompletion is not because of problems in LSP. The vscode Plugin takes the items from the openhab rest API http://openhab/rest/items, if that request is slow, then the autocompletion is as well. I noticed that amazon echo control for example slows down the rest api quite a bit. With 3 items from amazon echo control binding the items request took 1.5s, without them around 0.5s. This also influences the speed of the autocompletion. But this is not LSP related.

Quick test of removing most of my items, and openHAB does not hang, code completion works great. As soon as I add all of my items back, openHAB quickly hangs so there is something to this.

[SamuelBrucksch]

try time curl http://openhab:8080/rest/items/, how long does it run with all your items?

[airix1]

All in I have about 370 items. time curl rest items give me: real 0m0.548s user 0m0.036s sys 0m0.016s

[SamuelBrucksch]

Thats not the slowest i saw. I read about peoplehaving 2-6s. Maybe there are two issues not related to each other. The ticket in vscode extension was reopened, so the rest api thing might get sorted out somehow. Once that is done we will see if there is another issue with lsp.

[Confectrician]

The ticket in vscode extension was reopened

Yep, i am guilty for reopening this. 😄

I would like to encourage everyone to join the discussion in openhab/openhab-vscode#95, to find a valuable alternative for making auto completion suggestions possible in a more efficient way.

[mstormi]

See also #6410 which may or may not point to the reason behind.