> ## 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.

<a className="card-hover" href="https://www.dropbox.com/scl/fi/t7tt0q7dbg2wlcmlvpc7f/benchmark.pdf?rlkey=02k7e425gl5zfzkg3tif90nqp&e=1&st=n7oqctxu&dl=1" download="GoRules Benchmark.pdf">
  <Card title="Download benchmark report" icon="file-pdf">
    Full benchmark results with 74 decision scenarios
  </Card>
</a>

## 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

All benchmarks were run on 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>