Hi, Wolfgang, I think I’ve figured out some answers and see my shares below. Thanks and let me know your thoughts about #3. Best Abe 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. //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 These two rules try to validate if Matcher.getClauseNum() ==0 or <0. If you put differentiator “Matcher.getClauseNum()” at the end of LHS, Drools will start two threads to deduct RETE network so even if the fact hits rule 1, rule 2 will still be stepped in. But if we make the two rules as below, RETE will identify the shortcut correctly and no thread will be triggered to step into rule 2: rule "Evaluation of assignment in r-value position" no-loop true when eval(0==Matcher.getClauseNum()) $statement:CStatement($value:value) eval(Matcher.isRVExpression($value)) 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 eval(0<Matcher.getClauseNum()) $statement:CStatement($value:value) eval(Matcher.isRVExpression($value)) then System.out.println("=="+$value); Matcher.decreaseClauseNum(); modify($statement){ setSemantics(Matcher.getRVSemanticsWithoutUpdate(memory,$value)); } end 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. //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. 5.8.3.7. Conditional Element eval eval Figure 5.29. eval The conditional element eval is essentially a catch-all which allows any semantic code (that returns a primitive boolean) to be executed. This code can refer to variables that were bound in the LHS of the rule, and functions in the rule package. Overuse of eval reduces the declarativeness of your rules and can result in a poorly performing engine. While eval can be used anywhere in the patterns, the best practice is to add it as the last conditional element in the LHS of a rule. Evals cannot be indexed and thus are not as efficient as Field Constraints. However this makes them ideal for being used when functions return values that change over time, which is not allowed within Field Constraints. 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… 发件人: 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&gt; 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

So for #1, you mean it is more from static variable safety to put uncommon conditions at the beginning of LHS? On #3, can you elaborate more about " Making your rules depend on salience isn't good practice "? in general, what we need to define in every rule file is a business case, and every case stands for a flow with things like if-elseif-else. I guess you mean I may use Drools flow or Java itself to control the flow and leave judgment inside Drools? If that's the case, the original concern we had was it will have too many insert() into workingmemory which may impact performance... Best Abe -----邮件原件----- 发件人: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] 代表 Wolfgang Laun 发送时间: 2011年12月26日 23:15 收件人: Rules Users List 主题: Re: [rules-users] 答复: Performance consideration in rule writing On 26/12/2011, Zhuo Li <milanello1998(a)gmail.com&gt; wrote: 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. Needlessly using eval is not good; if you have to use it you won't be able to avoid it. > 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. 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))&&isCurrencyEqual > s($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))&&isCurrencyEqual > s($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