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> wrote:
From: Geoffrey De Smet <ge0ffrey.spam(a)gmail.com>
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>
wrote:
>
>> From: Geoffrey De Smet <ge0ffrey.spam(a)gmail.com>
>> 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