Optaplanner Drools 性能相当慢

Question

为了可维护性、可读性和易用性，我将我们的分数计算器重写为 Drools，我发现它的性能仅比我们的 EasyScoreCalculator 稍微好一点，并且比我们的 IncrementalScoreCalculator 慢得多。 （切换到 Drools 的主要原因是未能在 IncrementalScoreCalculator 中实施新规则）。

这是一个比较：

请注意，Drools 仅比 Easy 快一点，而 Incremental 比两者都快约 8-10 倍。

我们有很多规则，请注意，虽然有些规则与增量规则差不多快或快，但有些规则确实很慢，可能会形成瓶颈。

这是一个快速规则的示例（~18-20 k calcs/sec）

rule "The volume of all orders can't exceed the volume of the van"
    when $vehicle : Vehicle($capacity : capacity)
      accumulate(
        Customer(
          vehicle == $vehicle,
          $demand : demand);
        $demandTotal: sum($demand);
        $demandTotal > $capacity
      )
    then
      scoreHolder.addHardConstraintMatch(kcontext, 2, -Math.round($demandTotal - $capacity));
end

这是一个非常慢的规则示例（~1k calcs/sec）

rule "A shipment cannot be serviced outside of the shift's service hours"
  when
    $c: TimeWindowedCustomer( vehicle != null, this.isServicable() == true);
  then
    scoreHolder.addHardConstraintMatch(kcontext, 0, -1);
end

还有一个非常慢的规则的例子：

rule "Total used volume in future shifts"
  when
    $shift: Shift(isCurrent() == false)
    $vehicle: TimeWindowedVehicle($shift == shift, $capacity: capacity)
    accumulate(
      Customer(
         vehicle == $vehicle,
         $demand : demand);
      $demandTotal: sum($demand);
      $demandTotal > 0
    )
  then
    int utilisedFutureShiftVolumePenalty = Params.App.Solver.Scoring.utilisedFutureShiftVolumePenalty;
    long score = - utilisedFutureShiftVolumePenalty * Math.round($demandTotal);
    scoreHolder.addSoftConstraintMatch(kcontext, 1, score);
end

我知道这些缓慢的规则会形成瓶颈并减慢整个 drools 分数计算，但我无法弄清楚为什么这些规则会成为瓶颈。我唯一能想到的是，我在慢速规则中调用了一个方法，而在快速规则中我没有。

这是为什么调用对象方法的规则比其他方法慢得多的原因吗？如果是，为什么以及我应该怎么做？

谢谢！

Answer 1

isServicable() 是做什么的？它的作用可能远不止return servicable;。

至于第二个慢规则，它是Shift 和Vehicle 的叉积的累加。积累有点慢（没有insertLogical那么慢，但仍然）。

一旦我们发布它们，看看 ConstraintStreams 如何影响这些性能基准将会很有趣。