Performance

cargo bench runs criterion benchmarks (benches/grule_comparison.rs) that mirror Grule’s own, with the same rule set as Grule’s examples/benchmark/*.grl: 100 or 1000 identical rules plus one with higher salience, which matches and calls Complete().

Measured on an Apple M5. Grule’s figures come from its own benchmark documentation, on different hardware and across several runs, so compare orders of magnitude rather than exact ratios.

Where the difference comes from

• Executing stays nearly flat as rules grow: identical sub-expressions across rules are evaluated once, rule results are reused until a fact they read changes, and lower rules aren’t evaluated once the cycle’s best match is found. See Avoiding repeated work.
• Chains grow linearly with caching on, because each cycle only re-evaluates the rules whose inputs changed; with it off, every cycle re-evaluates every rule.
• Loading is a parse into compiled rules; Grule also builds its RETE network.

Keeping rules fast

• Load once, execute many times. Loading parses and compiles; execute reuses the compiled rules, and one engine can serve all threads.
• Prefer fields to methods in conditions. Conditions that call your functions or methods, log, or use Now() can’t be cached and are evaluated every cycle. A typed method also converts its fact with serde on every call. Computing a value once (in a high-salience rule, or before executing) and reading it as a field avoids both.
• Listeners and returned errors cost more. With a listener attached or set_return_err_on_failed_rule_evaluation(true), every rule is evaluated every cycle, as Grule does, so that each evaluation is observed.