对于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