[rules-dev] Why is this DRL twice as slow?

Greg Barton greg_barton at yahoo.com
Sat Aug 8 13:24:29 EDT 2009 

Yeah, that's what I meant by logical closure.  Possibly a bad choice of terms since "logical closure" has another meaning in set theory. 

At the moment there isn't such a functionality in drools, but Mark has mentioned before that he'd like it.  You could do something similar by not just asserting and retracting a single constraint, but asserting "impose constraint" and "remove constraint" objects.

--- On Sat, 8/8/09, Geoffrey De Smet <ge0ffrey.spam at gmail.com> wrote:

> From: Geoffrey De Smet <ge0ffrey.spam at gmail.com>
> Subject: Re: [rules-dev] Why is this DRL twice as slow?
> To: rules-dev at lists.jboss.org
> Date: Saturday, August 8, 2009, 11:11 AM
> >  Have you tried using an
> aggregator object that the constraints match and point to?
> 
> Incrementing such an aggregator object would not be a
> problem, but 
> decrementing is the problem.
> Is there some way I can have some code executed on the
> "retraction of a 
> logical inserted object"? That code could easily decrement
> the 
> aggregator object.
> 
> With kind regards,
> Geoffrey De Smet
> 
> 
> Greg Barton schreef:
> > About the accumulate caching, it does seem that it
> should make it tenable, doesn't it?  Possibly the "from
> must be reevaluated" aspect is getting in the way of that
> somewhere.  Edson, is that possible?
> > 
> > As for the "accumulate is poison for drools-solver"
> I'd have to say it's possible.  Any time you have a sum
> or work with aggregate functions it's a potential
> hazard.  You need to handle the change that contributes
> to the sum incrementally, and while the cached accumulate is
> supposed to handle that, maybe it's breaking down
> somewhere.  Have you tried using an aggregator object
> that the constraints match and point to?  (The
> reference from constraint to aggregator helps you
> efficiently determine if a constraint has been aggregated.)
> Of course it may require a logical closure functionality in
> drools to make it really work, (or at least convenient) but
> you could at least test if it performs better on the
> addition of constraint occurrences.
> > 
> > --- On Sat, 8/8/09, Geoffrey De Smet <ge0ffrey.spam at gmail.com>
> wrote:
> > 
> >> From: Geoffrey De Smet <ge0ffrey.spam at gmail.com>
> >> Subject: Re: [rules-dev] Why is this DRL twice as
> slow?
> >> To: rules-dev at lists.jboss.org
> >> Date: Saturday, August 8, 2009, 7:03 AM
> >> But even if it get re-evaluated
> >> twice, it cannot explain a performance 
> >> loss of more then 5%, let alone a a performance
> loss of
> >> 150%?
> >>
> >> If you take a look at the accumulate sum function
> >> implementation, you 
> >> 'll see that the total gets cached.
> >> That's also why an accumulate has "action code"
> and
> >> "reverse code".
> >>
> >> So since that sum total gets cached, I see no
> reason why
> >> this line:
> >>    $hardTotal : Number() from
> accumulate
> >> ...
> >> would take any noticeable time?
> >>
> >>
> >> I have a very strong feeling for a long time that
> >> accumulate functions 
> >> are poison for drools-solver. Yet I see no way to
> >> workaround them.
> >> Maybe we need some sort of "forward chaining
> accumulate"
> >> implementation?
> >>
> >> With kind regards,
> >> Geoffrey De Smet
> >>
> >>
> >> Greg Barton schreef:
> >>> As I understand it, the from keyword is not
> optimized
> >> in the way that it's output is not indexed. 
> Therefore
> >> if the set of objects matched changes it must
> rerun. 
> >> So when you have the two rules,
> "hardConstraintsBroken" is
> >> reevaluated when you change the hard constraints,
> and
> >> "softConstraintsBroken" is reevaluated when you
> change the
> >> soft constraints.  When there's just the one
> rule, it's
> >> reevaluated when either the hard or soft
> constraints
> >> changed, but BOTH accumulate expressions are
> evaluated every
> >> time.  Thus, 2x the evaluation time.
> >>> --- On Sat, 8/8/09, Geoffrey De Smet <ge0ffrey.spam at gmail.com>
> >> wrote:
> >>>> From: Geoffrey De Smet <ge0ffrey.spam at gmail.com>
> >>>> Subject: [rules-dev] Why is this DRL twice
> as
> >> slow?
> >>>> To: rules-dev at lists.jboss.org
> >>>> Date: Saturday, August 8, 2009, 5:46 AM
> >>>> Hi guys,
> >>>>
> >>>> I've run some experiments on the DRL's
> used in the
> >> drools
> >>>> solver 
> >>>> examination example to see how the DRL
> affects
> >>>> performance.
> >>>>
> >>>> In one experiment, I merged 2 rules into 1
> rule:
> >>>>
> >>>> I changed this DRL part of
> >> examinationScoreRules.drl:
> >>>> rule "hardConstraintsBroken"
> >>>>       
>    salience -1
> >>>>       when
> >>>>       
>    $hardTotal :
> >>>> Number() from accumulate(
> >>>>       
>    
> >>>>    
> >> IntConstraintOccurrence(constraintType ==
> >>>> ConstraintType.NEGATIVE_HARD, $weight :
> weight),
> >>>>       
>    
> >>>>     sum($weight)
> >>>>       
>    );
> >>>>       then
> >>>>       
> >>>>    
> >>
> scoreCalculator.setHardConstraintsBroken($hardTotal.intValue());
> >>>> end
> >>>>
> >>>> rule "softConstraintsBroken"
> >>>>       
>    salience -1
> >>>>       when
> >>>>       
>    $softTotal :
> >>>> Number() from accumulate(
> >>>>       
>    
> >>>>    
> >> IntConstraintOccurrence(constraintType ==
> >>>> ConstraintType.NEGATIVE_SOFT, $weight :
> weight),
> >>>>       
>    
> >>>>     sum($weight)
> >>>>       
>    );
> >>>>       then
> >>>>       
> >>>>    
> >>
> scoreCalculator.setSoftConstraintsBroken($softTotal.intValue());
> >>>> end
> >>>>
> >>>>
> >>>>
> >>>> into this DRL part:
> >>>>
> >>>> rule "constraintsBroken"
> >>>>       
>    salience -1
> >>>>       when
> >>>>       
>    $hardTotal :
> >>>> Number() from accumulate(
> >>>>       
>    
> >>>>    
> >> IntConstraintOccurrence(constraintType ==
> >>>> ConstraintType.NEGATIVE_HARD, $weight :
> weight),
> >>>>       
>    
> >>>>     sum($weight)
> >>>>       
>    );
> >>>>       
>    $softTotal :
> >>>> Number() from accumulate(
> >>>>       
>    
> >>>>    
> >> IntConstraintOccurrence(constraintType ==
> >>>> ConstraintType.NEGATIVE_SOFT, $weight :
> weight),
> >>>>       
>    
> >>>>     sum($weight)
> >>>>       
>    );
> >>>>       then
> >>>>       
> >>>>    
> >>
> scoreCalculator.setHardConstraintsBroken($hardTotal.intValue());
> >>>>       
> >>>>    
> >>
> scoreCalculator.setSoftConstraintsBroken($softTotal.intValue());
> >>>> end
> >>>>
> >>>>
> >>>> Now the performance for a 100 steps when
> from 71s
> >> to 172s,
> >>>> so it more 
> >>>> then doubled.
> >>>> All other code stayed the same and the
> output
> >> (except for
> >>>> the times) is 
> >>>> exactly the same.
> >>>> What can explain this loss in
> performance?
> >>>>
> >>>> -- 
> >>>> With kind regards,
> >>>> Geoffrey De Smet
> >>>>
> >>>>
> _______________________________________________
> >>>> rules-dev mailing list
> >>>> rules-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/rules-dev
> >>>>
> >>>
> >>>        
> >>>
> >>>
> _______________________________________________
> >>> rules-dev mailing list
> >>> rules-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/rules-dev
> >>>
> >> _______________________________________________
> >> rules-dev mailing list
> >> rules-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-dev
> >>
> > 
> > 
> >       
> > 
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> > 
> 
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>

More information about the rules-dev mailing list