Is the drl version of ProjectJobScheduling unusable?

Question

running the ProjectJobScheduling example with the drl configuration seems to take orders of magnitude longer to arrive at a feasible solution. For the "ProjectJobSchedulingIncrementalScoreCalculator version, it finds a feasible solution to a complex example problem in a couple of minutes, the drl version doesn't find one in two hours.

Is there a way to make the drl version usuable or does this type of problem require a java incremental score?

The only change I've made is:

<scoreDirectorFactory>
     <!--<incrementalScoreCalculatorClass>org.optaplanner.examples.projectjobscheduling.solver.score.ProjectJobSchedulingIncrementalScoreCalculator</incrementalScoreCalculatorClass>-->
   <scoreDrl>org/optaplanner/examples/projectjobscheduling/solver/projectJobSchedulingScoreRules.drl</scoreDrl>
  </scoreDirectorFactory>

EDIT: Commenting out the rule with insertLogical did increase the score/s by a factor of about 20 for the problem I was using.

So, I tried a few variations that don't use insertLogical, each with a single rule to replace the two I removed.(the insert rule and the accumulation of the insertedLogical) They were faster, but still impractically slow.

The "best" drl version for me is to add a problem Fact for each possible day from zero until a due Date, but deciding on a due date changes things:

rule "renewableResourceCapacity"
    salience 3
    when
        ResourceDay(  $day: usedDay)    
        $resource : Resource(renewable == true, $capacity:capacity)      

        accumulate(
            ResourceRequirement(resource == $resource,
                    $executionMode : executionMode,
                    $requirement : requirement)
            and Allocation(executionMode == $executionMode, $day >= startDate, $day < endDate);
            $used : sum($requirement);
            $used > $capacity
        )
    then
        scoreHolder.addHardConstraintMatch(kcontext, 0, $capacity - $used);
end

The fastest drl solution is still about 100 times slowed than the java version though. And to be clear, the modified drl is roughly 20 times faster than the existing drl, which is 100 times slower than the java.

Answer 1

There's probably a bottleneck rule in the DRL. One way to determine which one is to comment out a rule, run it for 1 minute and look at how the score calculation count differs. Do this for every rule (there are 4 or 5 or so) and you'll know which ones are expensive.

There's one rule using insertLogical which is never good for performance. That would be my main suspect.