Benchmarks🔗

Criterion benchmark results for the rsigma detection engine.

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

Freshness note. These figures were captured on rsigma 0.9.0; the workspace has since shipped through 0.13.0 and parts of the hot path (matcher dispatch, dot-path traversal, modifier validation) have changed. Treat the numbers as a baseline shape, not a per-release benchmark. To refresh for a specific release, check out the matching tag and run cargo bench per the commands listed in Running below; update the hardware/date/version block above when you do.

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 correlation
cargo bench -p rsigma-eval --bench correlation_memory   # peak-heap stress (not Criterion)
cargo bench -p rsigma-runtime --bench runtime_throughput
cargo bench -p rsigma-runtime --bench dynamic_pipelines

# 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 (0.11.x)🔗

Apple M4 Pro, macOS, release build, 2026-05-16. 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 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.65 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 no longer 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 (0.10.0)🔗

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. The crossover is clearly at 8.

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

Cross-Rule Aho-Corasick Pre-Filter, daachorse-index feature (0.10.0)🔗

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.

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 (0.15.0)🔗

Apple M4 Pro, macOS, release build, 2026-06-12. 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 (0.15.0)🔗

Apple M4 Pro, macOS, release build, 2026-06-12. 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) — exercises 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 1.10 Melem/s, tumbling 1.06 Melem/s, session 1.06 Melem/s — all 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).

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.

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.

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.

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.
• 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 173 ms to 1.71 ms (~101x). 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).
• Detection is fast: ~400K events/sec with 100 rules in pure evaluation mode, scaling linearly with event count.
• Runtime overhead is negative: LogProcessor with JSON batching is actually faster than raw Engine evaluation due to batch-level optimizations and format-aware parsing.
• Rule count scales well: Increasing from 100 to 1000 rules has minimal per-event cost increase (~50%) thanks to indexed field matching.
• Correlation is efficient: Temporal correlations (2.1M elem/s) are 2x faster than event-count correlations (1.05M elem/s), and both scale linearly with events.
• Window modes cost the same per event: sliding, tumbling, and session all run at ~1.4-1.5 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: 8 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 63 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.
• Template expansion is negligible: Even with 20 vars, expansion adds < 10 us. Not a bottleneck.
• JSONPath is the fastest extraction language: Roughly 2x faster than JQ for comparable filter operations on dynamic source data.
• CEL has high overhead: ~160x slower than JSONPath for list filtering due to interpretation overhead. 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.71M elem/s) is comparable to static pipeline performance.
• Reload is cheap: Engine rebuild with source re-resolution takes ~42 us (excluding network/file I/O). In production, reload latency is dominated by source fetch time.

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.