Benchmarks🔗

Criterion benchmark results for the rsigma detection engine.

Hardware: Apple M4 Pro, macOS
Profile: bench (optimized, release)
Date: 2026-05-07
Version: 0.9.0

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

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