> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gorules.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Performance

> Benchmark results and performance characteristics across ZEN Engine language bindings.

The ZEN Engine is written in Rust and achieves exceptional throughput across all language bindings. On a MacBook Pro M3 single-core, the engine processes an average of **91,000 evaluations per second** across 74 real-world decision benchmarks.

<Card title="Live benchmarks" icon="chart-line" href="https://gorules.github.io/zen/bench">
  Continuously updated cross-language benchmarks - every scenario measured in µs/op against the Rust baseline, with a snapshot timeline and per-binding comparison.
</Card>

## Benchmark highlights

| Scenario | Throughput |
| - | - |
| Realtime fraud detection | 191K req/s |
| Dynamic FX rate pricing | 184K req/s |
| Insurance agent commission | 148K req/s |
| Loan approval | 45K req/s |
| Company analysis (complex) | 4K req/s |

Performance varies based on decision structure. Pure decision tables and expression nodes achieve 150K+ evaluations per second. Decisions using [Function nodes](/learn/authoring/function-nodes) run slower (3-50K req/s) due to JavaScript runtime overhead.

## Language binding performance

All bindings share the same Rust core. The binding layer adds minimal overhead for most languages.

| Language | Binding | Overhead | Notes |
| - | - | - | - |
| Rust | Native | None | Baseline performance |
| Node.js | [NAPI-RS](https://napi.rs) | Low | Near-native, minimal serialization overhead |
| Python | [PyO3](https://pyo3.rs) | Low | Efficient type conversions, async support |
| Go | Custom C + CGO | Low | CGO boundary overhead, native evaluation |
| WebAssembly | WASM + NAPI | Low | Browser and edge deployments |
| Swift | [UniFFI](https://mozilla.github.io/uniffi-rs/) | Low | Idiomatic Swift APIs |
| Kotlin/Java/Android | JNA (UniFFI) | High | JVM boundary and object marshalling overhead |

## Performance optimization tips

**Pre-compile decisions.** Use `ZenDecisionContent` to parse and compile decisions once, then reuse them for multiple evaluations. This is available in Node.js, Python, and Go SDKs.

**Reuse engine instances.** Create a single engine at startup rather than instantiating per-request. Engine creation has initialization costs.

**Batch evaluations when possible.** If you're evaluating the same decision with many inputs, batch them to amortize any per-call overhead.

**Profile your specific decisions.** Performance varies significantly based on decision complexity. A simple lookup table runs 50x faster than a complex multi-stage graph with custom functions.

## Benchmark methodology

The [benchmark suite](https://gorules.github.io/zen/bench) runs the same real-world decision fixtures through the Rust core and each language binding, and publishes results per scenario in µs/op - Rust is the baseline floor, and the snapshot timeline shows how results evolve across engine releases. The headline figures on this page come from a MacBook Pro with Apple M3 chip using single-core execution. Each scenario represents a real-world business rule pattern:

* **Decision tables only** (100K+ req/s): Pure table lookups and expressions
* **Mixed graphs** (50-100K req/s): Multiple nodes, branching logic
* **Function-heavy** (3-50K req/s): Decisions using Function nodes with JavaScript execution

The benchmark measures pure evaluation time excluding I/O, network latency, and decision loading. Production throughput depends on your infrastructure, decision structure, and data serialization overhead.

<Note>
  The slowest benchmarks (Company analysis, Insurance breakdown, AML) use Function nodes extensively. If you need maximum throughput, prefer decision tables and expression nodes over custom JavaScript functions.
</Note>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.