Nools和Drools
我很高兴在Node中看到一个规则引擎，并且正在Java世界中看着Drools，并阅读文档（具体来说： http : //docs.jboss.org/drools/release/6.1.0.Final/drools -docs / html_single / index.html＃PHREAK）发现 Drools 6.0已经发展，现在使用PHREAK方法进行规则匹配。 感兴趣的具体段落是：
在RETE中每个成功的连接尝试都会产生一个将被传播到子节点的元组（或标记或部分匹配）。 出于这个原因，它的特点是一个元组为导向的algorithm。 对于每个到达的子节点，它将尝试与节点的另一端进行连接，每次成功的连接尝试都会立即传播。 这创build了一个下降recursion效果。 抖动节点的networking，从进入betanetworking到所有可到达叶节点的上下左右摇摆。
对于超过一定限制的复杂规则和规则，上面的引用说明了基于RETE的方法会对内存造成很大的影响，所以它演变成了PHREAK。
由于nools是基于Retealgorithm，所以上述有效？ 是否有类似于PHREAK的优化？ 与Drools做了什么比较？
当你想尝试并发和并行时，networking抖动只是一个问题。 由于NodeJS是单线程的，这不会是一个问题。 我们还没有试图在Drools这个领域解决这个问题，但是Phreak的工作就是在准备这个想法，从我们从Rete实现中发现的问题中学习。 在另一个说明中，Rete过去使用过分区algorithm来进行并行处理，而这项工作与它正试图解决的问题处于同一个区域。
对于单线程机器，懒惰的规则评估更有趣。 然而，正如文件所指出的那样，一个连接规则在Phreak和Rete之间的性能没有什么不同。 当你添加很多规则时，懒惰的本质避免了潜在的工作，从而节省了整个cpu周期。 该algorithm也更容许大量严重书写的规则，并且应该降低性能。 例如，它不需要用来驱动规则select和短路浪费匹配的传统Rete根“上下文”对象 – 这将在Phreak中被看作是反模式，并且可能实际上减慢它，当你吹走匹配它可能在未来再次使用。 http://www.dzone.com/links/rip_rete_time_to_get_phreaky.html
同样，当在规则中使用多个子networking时，例如具有多个累积的，面向集合的传播是相关的。 http://blog.athico.com/2014/02/drools-6-performance-with-phreak.html
我也跟进了反向链接和堆栈评估基础架构： http : //blog.athico.com/2014/01/drools-phreak-stack-based-evaluations.html
马克（Phreak的创造者）