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 <[email protected]> wrote: > >> From: Geoffrey De Smet <[email protected]> >> Subject: [rules-dev] Why is this DRL twice as slow? >> To: [email protected] >> 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 >> [email protected] >> https://lists.jboss.org/mailman/listinfo/rules-dev >> > > > > > _______________________________________________ > rules-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
