Editing Rete algorithm (section)

== Optimization and performance ==
Several optimizations for Rete have been identified and described in academic literature. Several of these, however, apply only in very specific scenarios, and therefore often have little or no application in a general-purpose rules engine.  In addition, alternative algorithms such as TREAT, developed by [[Daniel P. Miranker]]<ref>http://dl.acm.org/citation.cfm?id=39946 "TREAT: a new and efficient match algorithm for AI production systems
"</ref> LEAPS, and Design Time Inferencing (DeTI) have been formulated that may provide additional performance improvements.

The Rete algorithm is suited to scenarios where forward chaining and "inferencing" is used to calculate new facts from existing facts, or to filter and discard facts in order to arrive at some conclusion. It is also exploited as a reasonably efficient mechanism for performing highly combinatorial evaluations of facts where large numbers of joins must be performed between fact tuples. Other approaches to performing rule evaluation, such as the use of [[decision trees]], or the implementation of sequential engines, may be more appropriate for simple scenarios, and should be considered as possible alternatives.

Performance of Rete is also largely a matter of implementation choices (independent of the network topology), one of which (the use of hash tables) leads to major improvements.
Most of the performance benchmarks and comparisons available on the web are biased in some way or another. To mention only a frequent bias and an unfair type of comparison:
1) the use of toy problems such as the Manners and Waltz examples; such examples are useful to estimate specific properties of the implementation, but they may not reflect real performance on complex applications;
2) the use of an old implementation; for instance, the references in the following two sections (Rete II and Rete-NT) compare some commercial products to totally outdated versions of CLIPS and they claim that the commercial products may be orders of magnitude faster than CLIPS; this is forgetting that CLIPS 6.30 (with the introduction of hash tables as in Rete II) is orders of magnitude faster than the version used for the comparisons (CLIPS 6.04).