Rules condition behaviour

[noseve]

Morning All - does a rule skip to the next line immediately upon encountering an untrue condition?
Like most people - I imagine - I have rules with loads of conditions including groups and am wondering whether these are parsed regardless, or whether the rule will skip forwards as soon as it knows that it will NOT be triggering that particular line?
For a progressive set of rules - say, something race length dependent where only one will trigger - is there any benefit in adding 'if SVname not yet set' to the top of conditions on each line, or will that just exacerbate any lag?
FYI, this query is fired primarily by US markets, which can have a 'relaxed' attitude to the stated race time, necessitating an extended update period in Guardian.
Thanks in advance

[Dallas]

Rules and conditions within each rule are proceed in the order they appear in your file

So if you are settings a signal or stored value with rule 'A'
You need to ensure rule 'B' which has a condition to check those signal/stored value is situated below it in the file, if it sits above it then at the time its checked it won't be satisfied, rule 'A' would then trigger after this and you'd need to wait for the next time the market is refreshed for Rule 'B' to now see the signal/stored values

Like wise if you are setting multiple stored values in a rule/file, if you are performing and sort of calculation then you need to ensure they are in the correct order in each rule

[noseve]

Thanks for the reply, but I'm asking about a set of conditions on each single line.
If there are 12 conditions, say, and the first one dictates that the rule will not trigger, does the rule continue to wade through the other 11 conditions, even though it knows it will not be firing?
Or does it escape immediately to the next line?

[jamesedwards]

Thanks for the reply, but I'm asking about a set of conditions on each single line.
If there are 12 conditions, say, and the first one dictates that the rule will not trigger, does the rule continue to wade through the other 11 conditions, even though it knows it will not be firing?
Or does it escape immediately to the next line?

Good question. For more complex rules it would be handy to know whether multiple conditions cause potential delay or not.

[sionascaig]

Thanks for the reply, but I'm asking about a set of conditions on each single line.
If there are 12 conditions, say, and the first one dictates that the rule will not trigger, does the rule continue to wade through the other 11 conditions, even though it knows it will not be firing?
Or does it escape immediately to the next line?

I suspect not as you could have nested rules where only the 1st nest is false but 2nd nest is true & you only need 1 nest to be true in order to fire rule.

Then again maybe it is clever enough to take account of nested rules but that again would be an overhead.

My own view is that it will not make the slightest difference to most users and if it is really important to you then you are probably in the realm of bespoke solutions with everything optimised...

[Dallas]

Thanks for the reply, but I'm asking about a set of conditions on each single line.
If there are 12 conditions, say, and the first one dictates that the rule will not trigger, does the rule continue to wade through the other 11 conditions, even though it knows it will not be firing?
Or does it escape immediately to the next line?

I suspect not as you could have nested rules where only the 1st nest is false but 2nd nest is true & you only need 1 nest to be true in order to fire rule.

Then again maybe it is clever enough to take account of nested rules but that again would be an overhead.

My own view is that it will not make the slightest difference to most users and if it is really important to you then you are probably in the realm of bespoke solutions with everything optimised...

That's exactly right, they will all get checked but it happens so fast that you wouldn't notice the difference, unless you had 100+ rules, dozens of conditions and stored values performing multiple calculations etc and even then were probably talking a few milliseconds if that

[ShaunWhite]

That's exactly right, they will all get checked but it happens so fast that you wouldn't notice the difference, unless you had 100+ rules, dozens of conditions and stored values performing multiple calculations etc and even then were probably talking a few milliseconds if that

I'd be surprised if it was a millisecond tbh. On a modern system a line of code is executed in microseconds. If speed is an issue then there's other things to consider first.

[noseve]

they will all get checked

Thanks for clarifying that, Dallas.

Speed-wise, to be honest, that's what I'd have thought, considering that even this humble laptop in front of me could probably handle 500k MIPS. Nevertheless, what made me even consider the speed issue was an old thread I read - yonks ago - relating to history lists. It referred to a performance hit that poor use of them could generate. Maybe somebody was trying some aggressive BA-Excel streaming or similar, who knows? I was surprised to read it and have been conscious of any bottlenecks ever since.

Anyway, I shall happily ignore any effect of adding the odd extra lines from now on - fewer processes per line certainly make debugging a lot easier. Thanks all.

[sionascaig]

Anyway, I shall happily ignore any effect of adding the odd extra lines from now on - fewer processes per line certainly make debugging a lot easier. Thanks all.

Indeed... Have spent months checking the behaviour of some bots and trying to simplify.

Speed is way down my list of things to worry about as you can gtee that someone somewhere has a more optimal setup speed wise.