對于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上使用。

參考： DRL評分： Drools＆jBPM博客上來自我們JCG合作伙伴 Geoffrey De-Smet的OptaPlanner更快，更輕松 。

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

總結

以上是生活随笔為你收集整理的分数DRL：在OptaPlanner中更快，更轻松的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。