[rules-users] 答复: 答复: Performance consideration in rule writing

[Zhuo Li]

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 at lists.jboss.org
[mailto:rules-users-bounces at 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 at 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-bounces at lists.jboss.org
> [mailto:rules-users-bounces at 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>