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 <[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, 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 <[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 > _______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
