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 注释掉规则确实增加了 score/s 我正在使用的问题的大约 20 倍。

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

我的 "best" 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，这对性能来说从来都不是什么好事。那将是我的主要嫌疑人。

ProjectJobScheduling的drl版本是不是不能用了？

Is the drl version of ProjectJobScheduling unusable?

drools

optaplanner