Benchmarks

Criterion benchmark results for the rsigma detection engine.

Hardware: Apple M4 Pro, macOS
Profile: bench (optimized, release)
Date captured: 2026-07-05
Captured on version: 0.18.0 (main)

All suites below were rerun in full on the date above. To refresh for a specific release, check out the matching tag, run the commands in Running, and update the hardware/date/version block.

Running

# All benchmarks across all crates
cargo bench

# Individual suites
cargo bench -p rsigma-parser --bench parse
cargo bench -p rsigma-eval --bench eval
cargo bench -p rsigma-eval --bench eval --features daachorse-index   # includes the cross-rule AC suite
cargo bench -p rsigma-eval --bench logsource
cargo bench -p rsigma-eval --bench schema
cargo bench -p rsigma-eval --bench routing
cargo bench -p rsigma-eval --bench array
cargo bench -p rsigma-eval --bench correlation
cargo bench -p rsigma-eval --bench correlation_memory   # peak-heap stress (not Criterion)
cargo bench -p rsigma-eval --bench result_serialize
cargo bench -p rsigma-runtime --bench runtime_throughput
cargo bench -p rsigma-runtime --bench input_formats --features logfmt,cef,evtx
cargo bench -p rsigma-runtime --bench otlp --features otlp
cargo bench -p rsigma-runtime --bench dynamic_pipelines
cargo bench -p rsigma-runtime --bench enrichment
cargo bench -p rsigma-runtime --bench alert_pipeline
cargo bench -p rsigma-runtime --bench risk

# Specific benchmark group
cargo bench -p rsigma-eval --bench eval -- eval_throughput

# Quick mode (fewer samples, useful for CI smoke tests)
cargo bench -- --quick

---

Parser (rsigma-parser)

Rule Parsing

Wildcard and Regex Rules (pre-compiled pattern cache)

Wildcard/regex rule parsing is O(1) due to pattern caching (only the first parse compiles the patterns).

---

Evaluation Engine (rsigma-eval)

Rule Compilation

Rule Load Paths

Compares the three engine entry points for loading rules at large N. add_collection and add_rules rebuild the inverted and bloom indexes once at the end of the batch; add_rule in a loop folds each rule incrementally with an amortized-doubling bloom rebuild (64-rule floor, 2x ratchet).

All three paths scale linearly in the rule count. Per-rule cost is essentially constant from 1K to 100K, confirming the O(N) total complexity:

• add_collection and add_rules cost roughly 1.2-1.3 us/rule. The fixed per-batch cost is dominated by the final inverted index + bloom build over the aggregate.
• add_rule in a loop costs roughly 1.6-1.8 us/rule, about 40% more than the batched paths. The overhead is the per-rule incremental insert plus the ~11 doubling-watermark rebuilds the bloom triggers between 1 and 100K rules. There is no quadratic blowup; the constant factor pays for the incremental contract.

The takeaway is that add_rule is not a foot-gun for bulk loads. Batched APIs are still slightly faster and remain the recommended path for cold-load scenarios; the single-rule path exists for cases where the caller wants per-rule error reporting (rsigma rule validate) or per-rule mutation semantics.

Run with cargo bench -p rsigma-eval --bench eval -- rule_load.

Single Event Evaluation

Time to evaluate one event against N compiled rules.

Detection Throughput (100 rules)

Batch Mode (Sequential vs Parallel)

Wildcard and Regex Matching

Wildcard/regex matching scales O(1) with rule count thanks to compiled pattern sets.

Aho-Corasick Threshold Sweep

Single rule with N |contains patterns evaluated against 50 randomly generated events at varying haystack lengths. Drove the choice of AHO_CORASICK_THRESHOLD = 8 in compiler/optimizer.rs. Throughput is per event.

Throughput flattens at p=8: p16 and p32 perform within ~3% of p8 because the AC automaton scans the haystack once regardless of pattern count. Below 8 patterns, the sequential str::contains path with SIMD acceleration (memchr / Two-Way) wins on longer haystacks; at p8 the automaton already beats the p4 sequential path on short haystacks. The crossover stands at 8.

Run with cargo bench -p rsigma-eval --bench eval -- eval_ac_threshold_sweep.

Bloom Pre-Filter (--bloom-prefilter)

200 non-matching events evaluated against N substring-heavy rules with the bloom prefilter off vs on (Engine::set_bloom_prefilter(true)).

The bloom filter pays off from roughly 500 rules upward on non-matching traffic and is neutral below that. It never slows evaluation down in this workload, but it is opt-in because matching-heavy traffic pays the filter cost without the skip benefit.

Run with cargo bench -p rsigma-eval --bench eval -- eval_bloom_rejection.

Cross-Rule Aho-Corasick Pre-Filter, daachorse-index feature

200 non-matching events evaluated against N pure-substring rules. Best-case workload for the cross-rule index: every rule is AC-prunable (every detection consists exclusively of positive substring matchers, no negation in conditions), and every event has zero pattern hits across all fields.

The cross-rule index turns O(rules × patterns) per event into O(haystack_length) for the AC scan, so throughput is essentially constant in rule count once the index is enabled.

For typical mixed workloads (substring + exact + regex rules, events that hit multiple fields, smaller rule sets) the index adds build-time and lookup overhead with smaller wins or none, and can even cause a slowdown. Off by default. Enable via Engine::set_cross_rule_ac(true) programmatically, or --cross-rule-ac on rsigma engine daemon / rsigma engine eval (requires the daachorse-index Cargo feature). Always benchmark against representative data before flipping it on.

Run with cargo bench -p rsigma-eval --features daachorse-index --bench eval -- eval_cross_rule_ac.

Logsource Pruning (--logsource-routing)

Single-event evaluation over an always-evaluated (contains-only, never-matching) ruleset split 50/50 across product: windows and product: linux, with a windows-tagged event. With pruning on, the conflicting-product half is never iterated, so the win tracks the pruned fraction.

Run with cargo bench -p rsigma-eval --bench logsource.

Schema Classification (engine classify, --schema-routing, --observe-schemas)

Per-event cost of SchemaClassifier::classify against the built-in signature set. This is the hot-path overhead schema routing and schema observability add per event.

Classification stays well under a microsecond per event even in the full-scan worst case, so --observe-schemas and --schema-routing cost a fraction of a percent at typical pipeline throughputs.

Run with cargo bench -p rsigma-eval --bench schema.

Schema-Routed Dispatch (--schema-routing)

End-to-end routed evaluation over a mixed stream (one third ECS, one third flat Sysmon, one third unrecognized; 1,000 events, 100 non-matching rules), with ecs and sysmon bound to their builtin pipelines, against a single pipeline-less engine over the same stream.

The ~4.3 us/event difference overstates the dispatch cost: classification itself is ~0.3 us (see above), and most of the rest is the routed engines doing real matching work, because their pipeline-mapped rules reference fields the events actually carry (process.command_line), while the unrouted baseline’s unmapped rules miss ECS events on absent fields without ever scanning a value. That is the correctness gap routing exists to close: the baseline is faster partly because it silently cannot match two thirds of the stream.

Run with cargo bench -p rsigma-eval --bench routing.

Array Matching (sigma-version: 3)

Per-event cost of the array evaluation paths. Events carry a connections array of objects; the flat baseline is the same engine evaluating a single scalar field (326 ns). Array-scope bodies are evaluated per member rather than through the batched flat-field matchers, so cost is linear in member count.

Positional indexing is O(1) in the array length: args[0] costs 693 ns and args[-1] 671 ns against a 1,000-element array, about 2x the flat baseline for the index resolution.

Two properties fall out of the numbers. Non-firing evaluation costs ~35-60 ns per member (a 100-member [any] miss is 5.8 us, ~18x the flat baseline), and [all] exits early on the first failing member. But a firing rule pays ~110-250 ns per member regardless of where the matching element sits: [any] hit-first costs nearly the same as hit-last because the fan-out continues past the first hit to collect every matching member for match details. Budget array rules by array length times rule count on matching traffic, not by early-exit intuition.

Run with cargo bench -p rsigma-eval --bench array.

Result Serialization

Serializing EvaluationResult to the flat NDJSON wire shape, comparing the derive-based baseline against a #[serde(flatten)] variant and a hand-written Serialize impl.

All three implementations are within noise of each other; a hand-written serializer buys nothing, so the derive stays. Even a realistic correlation result serializes in under 2 us, an order of magnitude below its evaluation cost.

Run with cargo bench -p rsigma-eval --bench result_serialize.

---

Correlation Engine (rsigma-eval)

Event Count Correlation

1000 events evaluated against N correlation rules.

Temporal Correlation

1000 events evaluated with temporal ordering constraints.

Correlation Throughput

Sequential vs Batch (10,000 events)

State Pressure (unique group-by keys)

Window Modes: sliding vs tumbling vs session

Identical event_count workload for all three modes: 10,000 events across 1,000 group keys, one event per group per 10s tick, 1h window, 10m session gap. The window decision in apply_window_open is O(1) (deque front/back inspection), so the three modes cost the same per event.

Run with cargo bench -p rsigma-eval --bench correlation -- correlation_window_modes.

Window-Mode Memory Stress

The correlation_memory bench is not a Criterion suite: it installs a counting global allocator and reports peak and settled heap deltas over the engine baseline, isolating window-state maintenance (alert thresholds are unreachable; event construction is excluded from the deltas). It reproduces the two scenarios from the SEP #214 discussion on memory becoming the bottleneck in stateful window correlation.

A. High-cardinality session windows (one event per unique key, event_count, gap 5m, cap 2h), exercising the max_state_entries hard cap and stalest-first eviction:

A live session group costs ~256 B settled, dominated by the GroupKey heap strings rather than the timestamps. Throughput under active eviction is the highest of the three runs because the state map stays small; the eviction sort is amortized over the 10% headroom the cap reclaims.

B. Long-lived chatty sessions (groups emitting continuously inside an open session; gap never exceeded, so the per-group deque grows to timespan/interval entries):

C. Mode comparison (10k groups, 1M events, 1h window): sliding 915 Kelem/s, tumbling 959 Kelem/s, session 997 Kelem/s, all at a 6.6 MiB peak. Memory differences between modes come only from how long entries are retained, not from per-event overhead.

Run with cargo bench -p rsigma-eval --bench correlation_memory (about half a minute total).

---

Runtime (rsigma-runtime)

LogProcessor Pipeline Throughput

End-to-end processing: format parsing, detection, and result collection (100 rules).

Feature-Gated Input Formats (100 rules)

logfmt and CEF run through the same LogProcessor pipeline as the table above; EVTX measures EvtxFileReader binary-record parsing over the checked-in 2 MiB security.evtx fixture (~2,260 records), the dominant cost of engine eval -e @file.evtx.

Run with cargo bench -p rsigma-runtime --bench input_formats --features logfmt,cef,evtx.

OTLP Log Decode (otlp feature)

logs_request_to_raw_events: flattening an OTLP ExportLogsServiceRequest (string body, eight log attributes, four resource attributes, scope metadata, trace context per record) into the JSON events the engine evaluates. This is the ingest-side cost of OTLP/HTTP and OTLP/gRPC downstream of transport and protobuf decoding.

Decode costs a flat ~2.3 us per record independent of batch size, comparable to the JSON-line parse-plus-detect cost, so OTLP ingestion roughly halves single-core throughput relative to NDJSON input.

Run with cargo bench -p rsigma-runtime --bench otlp --features otlp.

Field Observability (--observe-fields)

The same 10,000-event JSON workload as above (seven fields per event, 100 rules) with the field observer off vs on.

The observer adds ~0.3 us per event on seven-key events (a mutex-guarded counter update per field key), about 25% of this workload’s total pipeline cost. Cheap in absolute terms, but it is the most expensive of the opt-in per-event observability features and scales with the event’s key count.

Run with cargo bench -p rsigma-runtime --bench runtime_throughput -- runtime_observe_fields.

Raw Engine vs LogProcessor (10,000 events, 100 rules)

Rule Scaling (1,000 JSON events)

Rule count has minimal impact on runtime throughput due to the engine’s indexed matching.

---

Post-Engine Layers (rsigma-runtime)

Sink-path stages that run after evaluation and before delivery. All figures are per 1,000-result batch; cardinality is the number of distinct entity/fingerprint values cycling through the batch.

Enrichment (template primitive)

The CPU-only floor cost of the enrichment pipeline: template interpolation, kind/scope filtering, semaphore acquisition, and the enrichments-map injection. I/O-bound primitives (http, command, lookup) are dominated by their fetch latency and response cache, not the pipeline.

Run with cargo bench -p rsigma-runtime --bench enrichment.

Alert Pipeline (dedup + incident grouping)

Dedup folding plus incident grouping cost roughly half a microsecond per result and grow gently with fingerprint cardinality (more open alerts and incidents to track).

Run with cargo bench -p rsigma-runtime --bench alert_pipeline.

Risk Layer (annotation + per-entity accumulation)

Single-entity is the worst case, inverted from the alert pipeline: every result accrues into one entity whose window deque keeps growing and whose accumulated risk repeatedly crosses the incident threshold. At realistic cardinalities the layer costs about a microsecond per result.

Run with cargo bench -p rsigma-runtime --bench risk.

---

Dynamic Pipelines (rsigma-runtime)

Source Resolution (File I/O + JSON Parse)

Data Parsing (No I/O)

Extract Expressions

Expression evaluation on a 100-item dataset with nested objects.

JQ times rose roughly 3x against the 0.9.0 baseline following the jaq 1.x to 3.0 migration (0.13.0, Radically Open Security audit fixes); JSONPath is unaffected and now ~10x faster than JQ for comparable filters.

Template Expansion

TemplateExpander::expand substituting ${source.*} references in pipeline vars.

Resolve with Extract (File + Filter, 500 IOC entries)

Dynamic Detection End-to-End

Full pipeline: resolve source, expand templates, apply value_placeholders, evaluate events.

Reload now includes the fail-closed dynamic-source re-resolution that load_rules performs since 0.14.0, which is why it costs more than the 0.9.0 baseline measured without it. In production, reload latency is dominated by source fetch time anyway.

---

Key Observations

• AC threshold is empirically 8: substring-list throughput flattens at 8 patterns once Aho-Corasick takes over. p16/p32 perform within ~3% of p8; below 8, the sequential str::contains SIMD path (memchr / Two-Way) is faster on longer haystacks.
• Cross-rule AC is order-of-magnitude on substring-only rule sets: with the daachorse-index feature enabled, 200 non-matching events against 10K pure-substring rules dropped from 187 ms to 2.05 ms (~91x). Off by default; only worth enabling for substring-heavy rule sets where most events don’t match (e.g., threat-intel feeds against high-volume telemetry).
• The bloom prefilter pays off from ~500 rules: ~20% faster on non-matching traffic at 1K-5K rules, neutral at 100. Opt-in because matching-heavy traffic pays the filter cost without the skip benefit.
• Logsource pruning wins track the pruned fraction: a 50/50 two-product split evaluates ~1.75x faster with --logsource-routing on, at both 1K and 10K rules.
• Schema classification is sub-microsecond: 216-548 ns per event against the full built-in signature set, so schema routing and observability are effectively free at pipeline throughputs.
• Array matching is linear in member count, and hits cost more than misses: non-firing paths cost ~35-60 ns per member while a firing rule pays ~110-250 ns per member independent of match position, because the fan-out collects every matching member for match details. Positional indexing (args[N]) stays O(1).
• Detection is fast: ~365K events/sec with 100 rules in pure evaluation mode, scaling linearly with event count; the full JSON runtime pipeline reaches 1.12M events/sec.
• Runtime overhead is negative: LogProcessor with JSON batching is faster than raw Engine evaluation due to batch-level optimizations and format-aware parsing.
• Rule count scales well: runtime throughput is flat from 100 to 1,000 rules thanks to indexed field matching.
• Correlation is efficient: temporal correlations (1.76M elem/s) are ~2x faster than event-count correlations (~900K elem/s), and both scale linearly with events; the mixed-workload pipeline sustains ~500K events/sec.
• Window modes cost the same per event: sliding, tumbling, and session all run at ~1.2-1.3 Melem/s on an identical workload. The window decision is O(1); choosing session over sliding is free at evaluation time.
• Correlation memory is bounded by entry count, not bytes: the max_state_entries cap (default 100k) held 1M unique session keys to a 39.8 MiB peak via stalest-first eviction. Within the cap, per-group deques grow with timespan x event rate: ~10 B per in-window event for event_count, ~92 B for value_count with distinct string values.
• value_count distinct counting is the correlation bottleneck: the distinct count is recomputed per event over the whole window (O(W) per event), so throughput drops from ~1.1 Melem/s to 57 Kelem/s at 1,800 distinct values per window; CPU collapses before memory does. Prefer shorter windows or event_count where distinctness is not required.
• Every wire format lands within one order of magnitude: JSON 1.1M, logfmt 631K, CEF 527K, and OTLP decode 440K events/sec per core, with EVTX binary parsing at 195K records/sec. Format choice moves single-core ingest capacity by at most ~2.5x.
• --observe-fields is the priciest per-event observability opt-in: ~0.3 us per event on seven-key events (~25% of the JSON pipeline cost on this workload), versus effectively free schema observation. It scales with event key count.
• Routed evaluation costs less than it looks: the ~2x gap versus an unrouted engine is mostly the routed engines doing real matching on pipeline-mapped fields the unmapped baseline can never match. Pure dispatch (classify + route) is sub-microsecond.
• Post-engine layers cost about a microsecond per result: template enrichment ~0.9 us, alert-pipeline dedup + grouping ~0.5 us, risk accumulation ~1.1 us at realistic entity cardinalities. At 10K detections/sec the full opt-in sink path consumes under 3% of a core.
• Result serialization is not worth hand-optimizing: the derive-based serializer matches a hand-written impl within noise; even realistic correlation results serialize in under 2 us.
• Template expansion is negligible: even with 20 vars, expansion adds < 10 us. Not a bottleneck.
• JSONPath is the fastest extraction language: ~10x faster than JQ for comparable filter operations since the jaq 3.0 migration, with none of CEL’s interpretation overhead.
• CEL has high overhead: ~150x slower than JSONPath for list filtering. Best suited for simple field access or small datasets.
• Dynamic pipelines add no per-event cost: once the engine is built, detection throughput with dynamic pipelines (2.85M elem/s) is comparable to static pipeline performance.

---

For operator-facing performance guidance (when to enable --bloom-prefilter and --cross-rule-ac, how to tune --batch-size and --buffer-size), see Performance Tuning. For the metrics that surface throughput and back-pressure at runtime, see Prometheus metrics and Observability.