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)
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?
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);
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}")
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?)
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.
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?
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 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.
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.
