I’ve been writing a bunch of new rules, and as a developer myself I’m curious if there’s certain ways to go about writing rules for performance. For example:
if/else if block, is there a more performant way to do that?And finally, I’m also curious if there’s any performance difference between the new rule engine and old one?
There’s some specific CPU hogs such as to use primitives on ARM, but that’s about it.
You are not supposed to do any scientific computing in rules and unless you do that you need not bother about performance.
I haven’t done any profiling myself. But Python rules seem quicker. OH 2.5 also seems to process the Python rules quicker than OH 2.4.
None of the things you have listed contribute to higher/lower performance. The rules DSL is a dog, especially if you feed it primitives. The new rule engine and scripted automation does not currently have any validation going on, which is a big part of the DSL rule loading time, but it also has no slowdown when using primitives.
The new rule engine and scripted automation w/ Jython offer so much more than what is available in the old rule engine, and there is no good reason to not migrate now rather than wait for OH 3.0. And yes, it is faster!
I have 20 rules files that run without any issue. You did not mention hardware. CPU and RAM could be an issue, but your post did not detail, so…
At the risk of repeating a lot of stuff already said…
Performance almost never matters in a home automation context. So what if it takes 500 msec to process an event that happens once every minute? There are cases where this does matter of course but usually the bottleneck is the technology, not Rules.
But usually, you will see sub 100 msec processing times on all but the most complex Rules DSL Rules unless you add sleeps or the like.
No, but it might be easier to read if you used a switch.
Not at runtime, maybe at openHAB start time.
Does not impact performance, but global variables are only global to that one file in Rules DSL.
Runtime performance, nothing I can think of. But the loading/parsing of Rules DSL Rules is very sensitive to type. The more you dictate the types of things, and especially if you force it to use primitives, the longer it’s going to take to load and parse your .rules files.
Scripted Automation is significantly faster, though I’m basing this on some very old tests that were done years ago back when it was using JSR223. I would not expect the results to change much. But, again, from a practical perspective, does it really matter if the Rule takes 10 msec to run or 5 msec to run?
We actually discovered a case where we could see an impact on this on Intel CPUs too. I think it’s just a feature of the language and it’s just more noticeable on ARM.
In general, if you are worried about performance, you are worried about the wrong things. There are only very few cases where the performance of even the most poorly written Rules DSL Rule will matter. So wait until you actually have a problem before worrying about performance.
Here’s where my “concern” is, or at least where my question originated from:
I have a one rule, where it’s syncing the state of two lights. So if I turn on one, it turns on the other. It actually happens completely in sync…i.e. it almost appears as if the lights were controlled by the same switch. I have another (more complex) rule where I have a switch controlling 3 smart outlets with lamps plugged in, and in this case there is a slight discernible delay. It’s not the end of the world obviously, but it did get me thinking.
So, I agree that in many/most cases, it’s not a. big deal if a rule takes 100ms vs 500ms to process, but I do think there are cases where that can make a noticeable difference.
In all likelihood the delay isn’t the rule, it’s the binding or the technology involved.