Disable the Language Server

I have a unique situation. I’m running a HestiaPi for my thermostat which I’m mostly happy with. But at it’s core it’s running openHAB on an RPi 0. I’m supporting them trying to skinny down the install and optimizing OH as much as I can to improve it as much as I can. As I was watching the logs I noticed the LSP starting up. Given the performance impact the LSP can have on OH running on even an adequate machine, I think it would be best to disable it on this HestiaPi. It’s adding a tiny bit to the boot time and if someone were to try and use it I think it would be pretty awful.

So my questions are:

  • I see three bundles that may be related to the LSP, disable all three?
    • org.eclipse.lsp4j
    • org.eclipse.lsp4j.jsonrpc
    • Eclipse SmartHome Language Server (it’s currently running OH 2.4, I plan on getting them upgraded to 2.5 but I want to make baby steps)

The jsonrpc one gives me pause as it looks like it might be use for more than just VSCode.

  • If I disable them will they become re-enabled on an upgrade? Will disabling them break something?

I’m just exploring options. Any advice is welcome.

Are you concerned about the memory footprint of those bundles, or the CPU consumption? If the latter, as long as you don’t have VS Code configured to use LSP (assuming you’re even using VS Code in this particular deployment), I doubt there’s much to worry about. If the former, then just disabling the bundles might not do much to reduce the memory footprint.

I’m actually mostly concerned with the amount of time it takes for OH to come up on this single CPU RPi 0 with too little RAM. But despite having too little RAM, it actually isn’t using all of what’s available. I’d like to prevent someone from trying to connect to the LSP to avoid that problem but I suspect I can achieve that via a firewall rule. So disabling it is to reduce the OH boot time as little bit. It takes 15-20 minutes for OH to boot on this machine. Obviously the bulk of that is rules and I’ve already made some good strides on that front. But every little thing adds up.

You, sir, are a very patient individual. :wink:

So, I wonder what would happen if you did a bundle:uninstall on all three of those bundles. Would it break OH somehow? If not, that might be your best starting point because I think that will prevent them from being loaded during startup (note I’ve not tried this). But, I expect they’ll get reinstalled after an upgrade (probably as a consequence of clearing tmp and cache), so you’ll need to be mindful of that.

Thanks, I’ll give that a try once I whittle down these Rules a bit to drop the boot time. I’ve already shaved a couple minutes off just by eliminating primitives. I’m now focused on reducing the overall lines of code. I think I can get it down by half which I’m hoping will reduce the rules parsing time by at least that much.

Of course once I do that I’ll move them all to NGRE and hopefully see further reductions in boot time. :wink:

The possibility to disable server side lsp would be something useful in general from my point of view.

3 Likes

Yes - maybe a simple config switch? I’d love to turn it off, too!

I think that would have to be done in openHAB core.
Do you have an idea @wborn?

Was this ever implemented?

/S

Not to my knowledge.
But maybe it is possible through openHAB console by stopping the bundle. (Not tested though.)

Uninstalling the bundle seems to work just fine on 4.1.0, but I’m sure it will come back on an openHAB upgrade, and possibly even installation of any addons.