对于OptaPlanner （= Drools Planner）6.0.0.Beta1，我已经用更优雅的ConstraintMatch系统替换了ConstraintOccurrence。 结果是您的DRL评分文件为：

• 快多了
• 更容易读写
• 错误的发生率要低得多，因为它们使分数损坏变得更加困难

让我们先看一下结果，然后再看一下代码可读性的改进。

快点

“给我看基准！”

平均计算计数 （即OptaPlanner每秒计算的分数数）已急剧增加。

• N个皇后：256个皇后的+ 39％计算数量
• 云平衡：平均计算量为+ 27％
• 车辆路线：平均+ 40％计算次数
• 课程安排：平均+ 20％计算数量
• 考试安排：平均+ 23％计算次数
• 护士花名册：平均Calc计数+ 7％

但是，这不一定意味着结果会得到显着改善，尤其是如果旧结果已经（接近）最佳的话。 这意味着您可以在更少的时间内获得完全相同的结果 。 但是-与所有其他性能改进一样- 无法保证在同一时间显着改善结果。 向外扩展时确实有帮助。

• 云平衡：5分钟内平均软得分+ 0.58％
• 车辆路线：5分钟内平均+ 0.14％可行软评分
• 课程安排：7分钟内平均+ 2.28％可行软评分
• 考试安排：7分钟内平均考试软得分+ 0.53％

30分钟的车辆路线数据集中的几个已经在5分钟内得到了最佳求解，因此尽管车辆路线加快的速度很高，但它们拖累了平均值。 所有基准测试都使用完全相同的Drools和OptaPlanner版本，因此这些数字仅显示ConstraintMatch更改的改进。 6.0中还有其他一些改进。

平均值如何计算计数范围？

这是一些图表，将旧的ConstraintOccurrence与新的ConstraintMatch进行了比较。 新的ConstraintMatch的当前实现尚未完全优化，因此有时将其称为“慢速”模式（即使速度更快）。

CloudBalance：

车辆路线：

课程安排：

考试名册：

更轻松

“给我看代码！”

对于初学者，将删除accumulateHardScore和accumulateSoftScore规则。 更少的样板。 接下来，每个计分规则的RHS（= then side）都更简单：

之前：

rule "conflictingLecturesSameCourseInSamePeriod"when...theninsertLogical(new IntConstraintOccurrence("conflictingLecturesSameCourseInSamePeriod", ConstraintType.HARD,-1,$leftLecture, $rightLecture));end

后：

rule "conflictingLecturesSameCourseInSamePeriod"when...thenscoreHolder.addHardConstraintMatch(kcontext, -1);end

请注意，您不需要重复ruleName或原因（讲座）。 OptaPlanner通过kcontext变量自行计算。 Drools自动在RHS中公开kcontext变量，因此您不需要任何其他代码。 此外，受限的ConstraintType枚举已由特定于Score类型的方法代替，以允许OptaPlanner更好地支持多级得分类型，例如HardMediumSoftScore和BendableScore。 您也不再需要修改API来获取所有ConstraintOcurrence的列表：ConstraintMatch对象（及其每个约束的总数）可直接在ScoreDirector API上使用。

翻译自: https://www.javacodegeeks.com/2013/04/score-drl-faster-and-easier-in-optaplanner.html