OH3: to use or not to use JS (ECMAscript 2021)

If you need it, it is available in newer versions.

No. openHAB 3.4.1 has absolutely NO changes in JS Scripting.
What’s the problem with „compilation“ takes about 50s? This is required once, after then the scripts run immediate. Anyway, I am wondering why the evaluation time increased from 15s to 50s. On my Pi it is 15s. The only one who knows what changed on your system is you, I can only tell you that openHAB 3.4.1 changed nothing at JS Scripting.

You have three options if you want higher speed:

  • Switch to a more powerful system
  • Disable the use of the built-in variables and manually import the required openHAB JavaScript library APIs (not sure if that really helps, just an idea)
  • Wait for openHAB 4

I have a compilation time of JS scripts of about 30s in OH4 on a Raspberry Pi 3. Is this ok? I think you have implemented some caching which reduces it to 2s?

Yes, I implemented caching of the library injection in https://github.com/openhab/openhab-addons/pull/14135, and as reported in the PR, I measured some nice performance improvements.
However it seems that those performance improvements are not as reproducible as we all wish.
After we had some problems where first evaluation of a script took longer with caching than without, I was able to fix that and @stefan.hoehn verified that caching helps.

What I really do not understand is, why compilation time is that different on systems that we think are the same. Can you please disable caching of the library injection and then measure compilation time? And which openHAB version are you using exactly?

Something we also found out that seems to be relevant, is 32/64-bit. It seems that GraalJS performs much better on 64-bit JDKs than on 32-bit, but this has to be verified by some more testing.

Please note that the compilation time is only a problem for UI-based rules/scripts at all.
For file-based rules, those files are loaded on openHAB startup or on file change, and therefore there is no compilation time on the first run of a rule.

I have done some performance tests on my Raspberry 3 with this script on openHAB 4.0.4.
Whenever I trigger a recompile by adding spaces to the script it takes 30-35s compilation time.
For development of new scripts this is pretty annoying as you always need to wait.
How can I disable the caching?

var item = items.getItem('ITEM');
console.info("Performance Test", item.name); 

It’s the second options in the addon settings.

I understand that you are set on jsscripting. I’m just curious how JRuby performs on an rpi 3, as I’ve never tested it and I cannot locate my rpi3. Would you mind doing a quick install test and uninstall?

The equivalent code is

item = items["ITEM"]
logger.info("Ruby test #{item.name}")

Do you mean this option?

This does not really make any difference in compilation time.

JRuby compilation took first time 25s, all next times 8s.
Interesting, faster than JS.

Wow! that’s still a long time! I run openhab on a xeon processor, so it’s generally about one second for the initial load I think. I’ve never timed it properly, because the file watcher itself has a bit of a delay (on purpose) upon detecting a file change.

Have you timed how long it takes to handle an event, not the initial script load time?
I hope it’s instantaneous with both jruby and js, even on an rpi3

Quick ruby script to test:
drop a file in conf/automation/ruby/test.rb

received_command(ITEM) { |event| logger.info "Ruby received command #{event.command} for #{event.item}" }

Then send a command to your ITEM item (e.g. using karaf side by side with log:tail?)

Yes exactly.

Hmm, that‘s not as it should be. Caching should speed up the compilation time (at least once any JS code has been compiled and the „cache“ is initialised) compared to non-caching. I really wonder why on some RPis it has significant effects, but on others nearly no effect.

@JimT I‘m glad you asked about JRuby. I guess this shows us that we cannot expect compilation times of 1-2 secs on an RPi 3 (Rules DSL also takes a few seconds to compile)!

My openHAB host has nothing comparable to a Xeon, but an Intel Celeron Quad-Core still is way more powerful than a Pi, so I am also not really able to test loading/compilation times. My Pi 3 unfortunately is on an older OS, which I need to upgrade before being able to perform any openHAB testing on it.

For JS, I can say, it is instantaneous. I have been using my Pi 3 as my openHAB host some time ago, and I can’t remember reading a report on the forum, where it was reported that script runtime was long.

I have setup a Raspberry 4 from scratch with OH 4.0.4. I created one item and did the JS test again.

First compilation 20s, next compilations 13-15s.
Better than the Raspberry 3, but I would have expected a recompilation time of some seconds.

1 Like

Same test on the Raspberry 4 for JRuby:
First time 7s, all next times 4s.

The scaling of JRuby on Raspberry 4 seems to be better. Is both JS and JRuby using Multithreading for compilation?

There is somewhere a different problem with your system. My production system has a 14 seconds delay at the first run and all subsequent runs have zero delay - it is lightning fast.
If you set up a system from scratch, do a test before you restore your data.
What is your CPU, RAM and Heap memory?

1 Like

I have no data restored. The system is from scratch with nothing. We are talking about compilation times. Of course once it is compiled it is “lightning fast”. But for development it is very annoying if you always have to wait some time until it is compiled.

sorry. I misunderstood this and thought you mean „next run“ (after compilation).
Then there is nothing wrong with your system as of now. No doubt that this is annoying but it is what it is at the moment.
Florian is aware of this and is working on it. At the moment you can try to install 64bit image, that will decrease the delay a bit more.

I know, thanks to Florian for his work! At the moment it is not a problem for me as I’m still using DSL.

1 Like

I did another test. On openhabian 1.9, 64bit, Pi5 the initial compilation time is1.5-2 seconds.
It does not make any difference whether you use GraalVM or any other openJDK.

64 bit or 32 bit?

Wow, that is as fast as I would expect it to be. Pretty much the same result as with a Pi 4 in Stefan‘s tests.
I guess GraalVM or OpenJDK „does not make any difference“ here because it is probably not enough code to be compiled to have a noticeable difference.