2011/12/26 Zhuo Li <milanello1...@gmail.com> > So for #1, you mean it is more from static variable safety to put uncommon > conditions at the beginning of LHS? >
A static variable or a DRL global is something that must be used with caution in a rule's LHS. In any case, if it is read, it should be used like a constant; if you modify it, it should be used like a one-way outoing service. > 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? Think of "flow" (either by Drools or by Java) as a high-level progress through application stages or phases. Salience is better restricted to precedence within flow groups, and there I don't recommend more than three levels. > If that's the case, the > original concern we had was it will have too many insert() into > workingmemory which may impact performance... > I don't see how one would require the other. Inserts are indicated if you derive new facts that need to be evaluated in subsequent rules. -W > > Best > Abe > > -----邮件原件----- > 发件人: rules-users-boun...@lists.jboss.org > [mailto:rules-users-boun...@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 <milanello1...@gmail.com> wrote: > > //Abe: it definitely makes a difference if you put differentiator > > conditions at the beginning �C 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. > > > > > > > > 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 �C 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-boun...@lists.jboss.org > > [mailto:rules-users-boun...@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 <milanello1...@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@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > > > > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > >
_______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users