简短的回答是，一旦规则数量超过某个（我不知道确切值）阈值，我希望规则引擎能够胜过命令式解决方案。
规则引擎的规则部分是一组条件和操作。单个规则（几乎）在功能上等同于 if - then 语句。由于引擎的声明性，规则引擎的真正力量得以体现。
在传统的命令式程序中，您必须编写如何评估逻辑的代码。使用规则引擎时，它决定了有多少语句被评估。我只使用过Jess或CLIPS等引擎，它们使用rete 算法来确定要触发哪些规则。规则触发算法的效率将推动规则引擎比传统的命令式解决方案更高效。
Rete 算法旨在牺牲内存以提高速度。它维护一个节点网络，将 LHS 侧模式映射到规则。你拥有的规则和事实越多，你的 rete 网络就将优于你的命令式解决方案，因为 Rete 性能在理论上与系统中的规则数量无关。
你正在计划很多事实。如果你计划有很多规则，你可能会遇到内存问题。
查看 Martin Fowler 关于规则引擎的文章。这是一个很好且（非常）简短的概述。
关于 Microsoft 业务规则引擎 (MS-BRE) 及其与 Jess & Drools 相比的性能，有一个冗长的讨论。提出的一些观点强调了为什么这些评估很难。
“谣言说它不是一个忠实的 rete 实现”是指一个古老的问题，涉及声称 BizTalk Server 包含的业务规则引擎未能正确实现 Rete 算法。顺便说一句，索赔是不正确的。BRE 确实实现了 Rete。WF 规则引擎是与 BRE 完全不同的技术。正如 Karl 所说，WF 规则引擎根本没有实现 Rete，无论是否正确。这是一个可以松散地称为“顺序”引擎的例子。它实现了一种前向链接的形式。然而，真正的问题比这要复杂一些。“前进”位是指引擎可以执行的逻辑推理类型。该术语并没有真正告诉您有关运行时涉及的机制的任何信息。真正的问题是关于引擎在推理方面的能力。是的，WF 可以前向链，是的，它可以推理，但仅限于非常有限的方式。Rete 引擎提供了更强的推理能力，但这实际上与 Rete 算法的使用无关，Rete 算法实际上只是对称为“生产”系统的某一类规则引擎的优化。这与生产系统可以对整个“事实库”进行推理的方式有关，而顺序 WF 规则引擎只能直接对单个事实的粗略等价物进行推理。有时会出现问题，因为人们将启用前向链接的特定运行时机制与前向链接本身的逻辑过程混淆（毕竟，这是一个非常微妙的区别）。WF 中的相关机制当然可以在有限的范围内以“前向”方式进行推理，但其主要用途是允许以半声明性方式表达顺序规则——即，可以以任何顺序表达规则无论这些规则之间的程序依赖关系如何。这与前向推理无关，或者实际上与前向链接的本地过程无关。
The issue is a little complex and obscure, and I know some of the guys at MS don't agree with me on this (we've discussed it often enough), but that's my take on it.
我们使用JBoss Drools在 7 分钟内通过 1500 条规则运行了 2400 万次测试，其中两个 JVM 在相当该死的普通服务器上运行。如果您运行每种组合，那么将运行超过 360 亿次测试，并且大多数测试中都有多种逻辑选择。（例如，您的示例有三个选择。）
需要非常注意的一件事是，WF 规则引擎实际上实现了自己的解析器，因此，它的表达能力有些受限，并且确实有性能考虑，因为它几乎是在进行字符串解析来解释规则在运行时进入代码（可执行操作）。
you would also have to consider how the data is passed into your rule engine, like once the rules starting to fire , and some rules makes calls to a DB , then surely it will have performance issues. the best practice is to give all the data needed for rule execution at the start itself , though this has some cons too.