Open cribskip opened 6 years ago
I've got a mitigation (at least for number or string items): By introducing a dummy state, the rule may be executed when the rule file is reloaded. This way the rule is compiled when triggered 'for real'.
Example:
rule "Lights" when Item Light received command
then
switch(receivedCommand) {
/* precompile dummy */
case 3: {
logInfo("Light", "Rule Lights now precompiled")
}
case 0: {
// Do Something
}
case 0: {
// Do Something
}
end
rule "Preload" when System started
then
Light.sendCommand("DUMMY")
end
It would be really great to have openhab do the precompile on its own - especially as this workaround is only possible for items where a dummy state may be possible.
Recent post regarding this problem: https://community.openhab.org/t/lazy-1st-execution-of-rule/47049
Hi,
Background as discussed several times in the community, rules executing the first time can cause significant delays as compilation happens.
https://community.openhab.org/t/solved-rules-first-time-slow-execution-after-some-use-fast/7042 https://community.openhab.org/t/openhab-2-rule-warmup-script-raises-the-waf/23125
In older versions, a mitigation had appearently been to include a "system started" rule per rule file and all rules got compiled, yielding to a immediate response once everything had been compiled.
I've tried several JIT-related options hoping to improve compilation times but it did not improve anything. I used parameters -XX:+AlwaysPreTouch, -XX:+BackgroundCompilation, -XX:CICompilerCount, -XX:+CICompilerCountPerCPU, -XX:+TieredCompilation and -XInt. Nothing improved the situation, interpreting made it as expected very slow.
The finding However, I noticed only one CPU getting busy when reloading a changed rule file. So I assume compilation is single-threaded. When openhab starts, all cores get busy but I have the impression it's not related to rule compilation because bindings get started. Once all bindings are started, rule compilation may continue for excessive "system started" rules - on a single core.
Proposal Maybe it's possible to multithread Xtend compilation, speeding up on multi-core but single-thread slow systems (ARM).
I've looked aroung but could not find anything on this.
Best regards, Sascha