From: Geoffrey De Smet <ge0ffrey.spam(a)gmail.com&gt; Subject: [rules-dev] Why is this DRL twice as slow? To: rules-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

From: Geoffrey De Smet <ge0ffrey.spam(a)gmail.com&gt; Subject: Re: [rules-dev] Why is this DRL twice as slow? To: rules-dev(a)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(a)gmail.com&gt; wrote: > >> From: Geoffrey De Smet <ge0ffrey.spam(a)gmail.com&gt; >> Subject: [rules-dev] Why is this DRL twice as slow? >> To: rules-dev(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> > > >        > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

From: Geoffrey De Smet <ge0ffrey.spam(a)gmail.com&gt; Subject: Re: [rules-dev] Why is this DRL twice as slow? To: rules-dev(a)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(a)gmail.com&gt; wrote: > >> From: Geoffrey De Smet <ge0ffrey.spam(a)gmail.com&gt; >> Subject: Re: [rules-dev] Why is this DRL twice as slow? >> To: rules-dev(a)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(a)gmail.com&gt; >> wrote: >>>> From: Geoffrey De Smet <ge0ffrey.spam(a)gmail.com&gt; >>>> Subject: [rules-dev] Why is this DRL twice as >> slow? >>>> To: rules-dev(a)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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>> >>> >>>        >>> >>> _______________________________________________ >>> rules-dev mailing list >>> rules-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> > > >        > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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?