Java 根据规则库大小，在工作内存中插入事实的时间会增加

我在我的系统中执行一些评估实验，检查插入不同（规则数量）规则库所需的时间以及内存中的事实数量。注意：我没有使用persistence。Drools版本：6.3.0.Final

表-规则库（RB）、插入时间（TTI）、以毫秒为单位的时间。

根据上面预设的表格，我想知道为什么当规则库大小增加时，将事实包含在内存中的时间会增加

---

我不是Drools方面的专家。

事实插入、收回和更新会在给定网络状态下尽可能即时评估条件。这不仅仅是规则的数量；重要的是事实类型的引用数量

你观察到一个小于O（N）的增长，N是规则的数量，这很好地符合理论

12000条规则的数量是非常惊人的（除非你发明规则只是为了测试可伸缩性）。如果它们是真实的，并且您担心性能，那么您应该修改规则结构

根据OP的评论进行编辑

“事实类型的引用次数”是某个类（=类型）在模式中出现的次数。在你的例子中

rule x when
$spec1 : Specification ( )
$spec2 : Specification ( $spec1.id ==2, id == 3, value > $spec1.value )

rule "x+1" when
$spec1 : Specification ( )
$spec2 : Specification ( $spec1.id ==3, id == 4, value > $spec1.value )

您有2条规则，但有4条对

规范的引用。这必然会在引擎中创建更复杂的网络。此外，仅依赖于第一个模式中的数据（
$spec1.id==X
）但发生在第二个模式中的约束几乎肯定是反模式的

使用像这样糟糕的结构，几乎没有限制地减慢RBS的速度，而不仅仅是流口水。显然，您实际上只是在测试可伸缩性。坚持写得好的规则可能会给你更多的结论性结果。
你在使用持久性吗？这将是罪魁祸首之一。另一件事是，在会话中，规则的左侧（when部分）在插入事实时进行计算。所以规则越多，评估越多，时间就越多。我不是在坚持。非常感谢。所以，我不是100%肯定这一点，但我读到了一个技巧。你想试试吗？在您的规则中，添加另一个匹配对象，就像任何随机对象一样。这将导致所有规则仅在该对象可用时才计算为true。现在将您的3/6/12k事实插入会话。不要插入最后一个对象，直到最后一个对象。这将导致引擎在O（1）中对所有事实求值为false，然后在启用规则的最后一个额外事实处对所有事实进行功率匹配。