> 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 <[email protected]> wrote: > >> From: Geoffrey De Smet <[email protected]> >> Subject: Re: [rules-dev] Why is this DRL twice as slow? >> To: [email protected] >> 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 <[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 >> > > > > > _______________________________________________ > 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
