Drools 6引入了新的惰性匹配算法。 該算法的詳細信息已在之前的兩個博客中介紹：

• RIP RETE時間獲得PHREAKY
• 基于PHREAK堆棧的評估和向后鏈接

第一篇文章討論了性能以及為什么算法的批處理和惰性方面難以比較。

“性能的最后一點。 通常，使用PHREAK的單個規則不會比使用RETE更快。 對于使用根上下文對象啟用和禁用匹配的給定規則和相同數據集，它們都嘗試相同數量的匹配并產生相同數量的規則實例，并且花費的時間大致相同。 除了帶有子網的用例和積累。

但是，對于規則編寫得不好的規則庫，PHREAK可以認為比RETE更寬容，并且隨著規則數量和復雜性的增加，性能會更適度地下降。

RETE還將為不包含所有聯接的數據的規則生產部分機器。 PHREAK會避免這種情況。

因此，并不是PHREAK比RETE更快，它不會隨著系統的增長而降低速度！”

最近，OptaPlanner團隊開始對ReteOO和Phreak之間的同一組規則進行基準測試： 哪種規則引擎算法更快：ReteOO還是Phreak？

他們發現，三項測試的速度提高了20％，一項測試的速度降低了4％。 用戶對該文章發表了評論，其性能差異為17％。

OptaPlanner團隊投入了很多時間來確保編寫規則的方式不會碰到Rete墻。 他們消除了許多問題，例如在一條規則中進行多次累加。

一個用戶對如果您以已知的方式導致ReteOO出現問題而實施規則會感興趣，那么它將更優雅地處理它。 他們創建了4條規則，每條規則都有兩個累加。 您可以在此處找到DRL文件，其中一個規則的副本如下所示：

rule gold_account whenaccount: Account()Number(this >= 50000) from accumulate(t: Transaction(source == account); sum(t.amount))Number(this >= 50000) from accumulate(t: Transaction(target == account); sum(t.amount)) then//System.out.println("Gold account: " + account); end

結果令人鼓舞，Phreak的性能提高了400％（5倍）:)這主要是因為Phreak可以分批評估規則，從而避免了很多浪費的工作。 它肯定表明我們已經實現了上一段中引用的目標之一：

“不過，PHREAK可以認為RETE對于編寫得不好的規則庫比RETE更為寬容，并且隨著規則數量和復雜性的增加，性能會更加適度地下降。”

• 如果您想自己嘗試一下，可以在這里簽出項目： https : //github.com/winklerm/phreak-examples

到目前為止，該算法是為正確性而設計的，尤其是在線程安全性和將來的多核開發方面。 因此，這僅僅是開始，我們還有很多優化和改進要做。

參考： Drools ＆jBPM博客上我們JCG合作伙伴 Geoffrey De Smet 的PHREAK算法帶來的Drools 6性能 。

翻譯自: https://www.javacodegeeks.com/2014/02/drools-6-performance-with-the-phreak-algorithm.html

總結

以上是生活随笔為你收集整理的使用PHREAK算法实现Drools 6性能的全部內容，希望文章能夠幫你解決所遇到的問題。

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