ProjectJobScheduling的drl版本是不可用的吗？

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注释掉规则确实将我使用的问题的得分/ s提高了大约20倍。

所以，我尝试了一些不使用insertLogical的变体，每个变量都有一个规则来替换我删除的两个。（插入规则和insertedLogical的累积）它们更快，但仍然不切实际慢。

对我来说，“最好的”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，这对性能永远不利。这将是我的主要嫌疑人。