10:32 a.m.
2011/12/26 Zhuo Li <milanello1998(a)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-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> wrote:
> //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.
>
>
> 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))&&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
>
>
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users