Hi Florian,
not sure if you remember this problem. It was about the fact that JS code needs to be evaluated once before it is cached.
I haven’t used JS scripts since but I did another test today on v4.0.1 as I wanted to start again transitioning my DSL rules to JS.
I can see in the logs that there was a delay of 20! seconds for the very first JS script.
(starting point is time stamp of changing an item state,
end point is time stamp of loginfo of script).
Then I ran more (different) scripts which all had a delay of 13 seconds when they were run for the first time.
All test scripts just had to do a sendCommand to an item.
All scripts were executed without any delays when run second time.
For the first run of any script, it takes (a bit) longer than following runs, because the engine has to initialise once on the first run, in subsequent runs it is already initialized.
Yesterday I found out, that the performance with caching became really worse compared to what I measured when I implemented caching.
It turned out, that a change to openhab-js‘ webpack config affected the performance of the injection of the cached library. I have fixed that regression yesterday and @stefan.hoehn and my confirmed the fix, it will (very likely) be included in the next SNAPSHOT and I also want to backport it to 4.0.x.
I think, it is no problem if you run a dummy script once to get the cache filled. But the current situation is you need to fill the cache per each single script. Is there a way to optimise it so that it comes down to one „dummy“ script?
There currently is a bug that effectively breaks the caching, once the fix is tested and backported to 4.0.x, the first script to run initialises the cache for all other scripts, so you can use a “dummy” script, or if you use file-based rules, you don’t need a “dummy” script.
Hi Florian,
thanks for your attempt to solve the bug but unfortunately the bug still exists in 4.0.2.
A JS script still needs 16-19 seconds until it is executed.
Can I help with some debug logs?
