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

Have you tried using an aggregator object that the constraints match and point to?

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