Re: [rules-users] 答复: Performance consideration in rule writing
On 26/12/2011, Zhuo Li <milanello1998(a)gmail.com> wrote:
> 3. What’s you guys’
naming convention for rule’s salience?
> Not clear what you mean by that.
> //Abe: I mean how do you weight your salience values
across different rules.
> I’ve seen various styles in my project � somebody uses 100, 200, 300 but
> somebody uses 90, 100, 110, 120, etc. This is not a big problem as they are
> working on different rules and won’t pollute each other. However I would
> still try to make it consistent so maintain each other’s rule files will be
> easier…
Making your rules depend on salience isn't good practice, certainly
not with more than 3 levels (my personal definition). The sort of
multi-level salience you're indicating could be an indication that
procedural style if-then-elsif logic has been fitted into rules.
-W
> 发件人:
rules-users-bounces(a)lists.jboss.org
> [mailto:rules-users-bounces@lists.jboss.org] 代表 Wolfgang Laun
> 发送时间: 2011年12月26日 22:20
> 收件人: Rules Users List
> 主题: Re: [rules-users] Performance consideration in rule writing
> See
below.
> 2011/12/26 Zhuo Li <milanello1998(a)gmail.com > Hi, team,
> I
have some quick questions here regarding performance best practices of
> rule writing. See below two pieces of rules:
> Rule
“1”
> Salience 100
> No-loop true
> When $txn : data(sourceid ==
5&&txnjustify==”995”
>
&&eval(creditOption($txn)==1)&&eval(isGCSwitch($txn))&&isCurrencyEquals($txn
> )==0&&compareToPostThreshold($txn)==2);
> Then
> …
> End
> Rule
“2”
> Salience 100
> No-loop true
> When $txn : data(sourceid ==
5&&txnjustify==”995”
>
&&eval(creditOption($txn)==1)&&eval(isGCSwitch($txn))&&isCurrencyEquals($txn
> )==0&&compareToPostThreshold($txn)==1);
> Then
> …
> End
>
Questions:
> 1. Will I gain better performance if I put the rule
differentiator
> condition “compareToPostThreshold($txn)==2” at the beginning of both rule
> 1 and 2?
> One kind pf Rete optimization is based on evaluating
common constraints
> once, therefore: no.
> 2. I saw salaboy’s video
claiming that to avoid using eval() in the
> rule. Do we have any alternative way to do that from a performance
> consideration
> Constraints based on fields using == are best. Other
things may result in
> eval-like evaluations anyway. Most of the time, it isn't eval that causes
> performance setbacks.
> or I’d better collect/ prepare all the data before I send
them into the
> session?
> Not clear what you mean by this, but if you can provide
attributes that lend
> themselves to straightforward constraints it might be worthwhile considering
> some up-front processing of facts.
> 3. What’s you guys’
naming convention for rule’s salience?
> Not clear what you mean by that.
> -W
> PS: my Drools version is 5.2.0.
> Best
regards
> Abe
>
_______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
//Abe: it definitely makes a difference if you put differentiator
conditions
at the beginning � this way RETE won’t waste efforts constructing networks
which will not fulfill. See below example.
rule "Evaluation of assignment in r-value position"
no-loop true
when
$statement:CStatement($value:value)
eval(Matcher.isRVExpression($value))
eval(0==Matcher.getClauseNum())
then
System.out.println($value);
modify($statement){
setSemantics(Matcher.getRVSemantics(memory,$value));
}
end
rule "Evaluation of assignment clause in r-value position without updating
memory"
no-loop true
when
$statement:CStatement($value:value)
eval(Matcher.isRVExpression($value))
eval(0<Matcher.getClauseNum())
then
System.out.println("=="+$value);
Matcher.decreaseClauseNum();
modify($statement){
setSemantics(Matcher.getRVSemanticsWithoutUpdate(memory,$value));
}
end
This is quite different from the rules in the original post. It is
generally not advisable to access and modify static variables, here:
clauseNum in class Matcher, i.e., not a fact.
//Abe: I saw below statement from Drools document 5.2.0. As Eval is
not
indexed, overuse of evale reduces the rules’ clarity and will result in a
bad performance.
Needlessly using eval is not good; if you have to use it you won't be
able to avoid it.