I have think of this issue later, and think the optimization can be done on
some module such as the groovy-drools. Here is some ideas:



1. For a RuleBase, we can collect all the rule's condition together

2. We can merge f.name or f.getName() expression together, so once 1 expr
called f.getName(), it can be reused in another expression.

3. calculate some expression-expression relationship, such as if (f.a ==
"a") then f.a != "b", or if(f.a >3) then !(f.a < 2).



It looks to do such optimization, it is possible but still require a lot of
work, maybe somebody have the time can do it.




2005/12/13, Michael Neale <[EMAIL PROTECTED]>:
>
> in that particular example, in the one rule it is moot as only one
> condition
> has to be false.
>
> But that is an interesting optimisation - for normal declarative rules -
> we
> would have to tell the engine that one condition implies the other. I am
> not
> sure if there are any existing optimisations that provide this without
> asking for more information from the rule author (which would be a bit
> error
> prone).
>
> Go ahead and do a Proof of concept if you think it would help prove or
> disprove.
>
> Michael.
>
>
>
>
> On 12/6/05, 王在祥 <[EMAIL PROTECTED]> wrote:
> >
> > I am a newer to drools, and i find that drools dont optimize the
> following
> > case:
> >
> > <rule1>
> >    <condition>f.a == "this"</condition>
> > </rule>
> >
> > <rule2>
> >    <condition>f.a == "that"</condition>
> > </rule>
> >
> > in my understand, if rule1.condition f.a == "this" is true, then
> > rule2.condition will be false and without a evaluation.
> >
> > Maybe we should add some support to the org.drools.spi.Condition two
> > methods:
> > 1. boolean implies(Condition other)  return true if this condition
> implies
> > other condition, so when this condition eval to true, then the other
> will
> > be
> > true
> > 2. boolean impliesNot(Condition other) return true if this condition
> > implies
> > not the other condition, so when this condition eval to true, the other
> > will
> > be false.
> >
> > also optimize the rateoo engine to avoid evaluate conditional based on
> > these
> > methods.
> >
> > Do you think so?
> >
> >
>
>

Reply via email to