Question

使用drl配置运行ProjectJobScheduling示例似乎需要更长的时间才能获得可行的解决方案。对于“ ProjectJobSchedulingIncrementalScoreCalculator版本，它可以在几分钟内找到解决复杂示例问题的可行解决方案，而drl版本在两小时内找不到。

有没有办法使drl版本可用，还是这种类型的问题需要Java增量分数？

我所做的唯一更改是：

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

编辑：使用insertLogical注释掉该规则确实使我使用的问题的得分提高了约20倍。

因此，我尝试了一些不使用insertLogical的变体，每个变体都有一个规则来替换我删除的两个规则（insert规则和insertLogical的累加），它们虽然更快，但仍然不切实际。 / p>

对我来说，“最佳” drl版本是为从零到到期日期的每个可能的日期添加一个问题事实，但是决定到期日期会改变事情：

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

最快的drl解决方案仍然比Java版本慢100倍左右。需要明确的是，修改后的drl大约比现有drl快20倍，比java慢100倍。

Answer 1

DRL中可能存在瓶颈规则。确定一条规则的一种方法是注释一条规则，将其运行1分钟，然后查看分数计算计数的差异。对于每条规则（大约有4或5条）执行此操作，您就会知道哪些规则比较昂贵。

有一个规则使用insertLogical永远不会对性能有好处。那将是我的主要嫌疑犯。

drl版本的ProjectJobScheduling不可用吗？

1 个答案: