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.

Synthetic vs. representative workloads

Every Criterion table below uses synthetic rules and events built by benches/datagen.rs. Those rules are dominated by exact field matches, which the candidate index prunes to a handful of candidates per event, so the per-event cost in tables like Single Event Evaluation stays nearly flat as the rule count grows. That flat scaling still does not transfer to real rule corpora, though the gap has narrowed considerably: witness-based indexing gates substring, keyword, regex, and numeric rules too, so a SigmaHQ-scale corpus now evaluates a few percent of its rules per event rather than the ~79% the earlier exact-only index left always-evaluated.

Use the representative baseline below, not the synthetic tables, to size deployments that load SigmaHQ-scale corpora.

SigmaHQ corpus baseline (representative)

Hardware: Apple M4 Pro (8 performance + 4 efficiency cores), macOS
Date captured: 2026-07-28
Corpus: SigmaHQ rules/ at 994da166 (3,132 detection rules, the SHA pinned in CI)
Fixtures: scripts/perf/fetch-fixtures.sh (pinned corpus + deterministic event lanes), run via scripts/perf/baseline-eval.sh and scripts/perf/daemon-matrix.sh, both against the same two binaries via their RSIGMA override. The offline harness now reports the median of three measured runs; the daemon matrix also covers --include-event and a handcrafted correlation lane. scripts/perf/image-compare.sh races two container images over the same fixtures instead of two native binaries, which is how cost that only the released artifact carries becomes visible; it needs Docker but no Rust toolchain and no local k6.

Method: each lane is concatenated to 100,000 events and the reported rate is net of rule load. Loading the pinned corpus costs ~0.3 s, which is a fixed startup cost; leaving it in a per-event figure over a single 10k-event pass made a faster evaluator look slower than it is, and earlier captures of this section understated throughput by roughly 2x for that reason. Both columns are printed by the harness so the split stays visible. engine eval is single-threaded: RAYON_NUM_THREADS makes no measurable difference to it, so these are per-core numbers.

Offline engine eval, single core, before and after witness-based candidate indexing. Match counts are identical in every cell, which is what makes the comparison a throughput measurement rather than a behavior change:

Daemon HTTP end-to-end (--input http --batch-size 512, 4 concurrent NDJSON batch posters, throughput from the daemon’s own rsigma_events_processed_total delta, so an HTTP accept backlog cannot inflate it):

--cross-rule-ac changed sides. Before witness indexing it earned its keep on top of routing (31.8k vs 25.9k on the raw-blob lane end-to-end). After, --logsource-routing alone beats every AC configuration on all four lanes both offline and end-to-end, and adding AC on top of routing costs 20-35%. The candidate index performs the same substring work over a smaller rule population, so the cross-rule automaton is now a duplicated hot-path pass. It stays correct and feature-gated for pure-substring corpora at 5,000+ rules, where it should be benchmarked against routing rather than against the bare default.

Parallel efficiency fell as per-event cost did, which is the expected shape and locates the next bottleneck. On the raw-blob lane the daemon delivered 7.8x its single-core rate before (20,193 over 2,601) and 5.8x after (195,639 over 33,884) on 8 performance cores. On the cheapest configurations the ratio is lower still: the Cisco lane with routing scales 3.8x (401,364 over 106,241). Detection itself does parallelize inside a batch, since Engine::evaluate_batch fans a batch across rayon when the parallel feature is on, so what the remaining gap represents is the fixed per-event pipeline cost around evaluation (HTTP framing, JSON parse, result serialization, sink write) plus the engine lock the batch is held under.

The formatted daemon path now parses lines in parallel before taking the engine mutex, while a separate ordering lock keeps one batch in flight and preserves correlation and output order. On the raw Windows lane with --logsource-routing, --batch-size 512, 16 k6 VUs, and the same pinned corpus, a same-build median-of-three comparison moved 8-thread throughput from 306,351 to 384,906 events/s while one-thread throughput stayed near 90,000 events/s. Scaling improved from 3.39x (42% efficiency) to 4.19x (52% efficiency); parse share at eight threads fell from about 40% to 27%. Repeated runs after sustained compilation and benchmarking measured 50-52% efficiency, so parsing was confirmed as a major bottleneck but not the only serial cost. A Bytes/request-body-span prototype did not improve this workload and was not retained; the daemon does retain single-parse DLQ routing, eliminating its previous validation parse.

Phase timing after that change showed evaluate still ~71% of measured batch time at eight threads. Sampling profiles attributed most of that to candidate-index field probes and JsonEvent::get_field misses over absent Sigma fields. Probing only witnesses under the event’s top-level keys, plus a dotted-path root fast-miss in get_field, raised the same routed daemon median from about 93k to 102k events/s at one thread and from about 386k to 404k events/s at eight threads on the same host.

Those ratios hold only when the allocator scales with the fan-out, which is a property of the build rather than of the engine. Every figure above is a native build against the system allocator, while the released ghcr.io/timescale/rsigma binary is static musl, and musl’s mallocng serializes the concurrent allocation evaluate_batch performs. Until jemalloc became the musl global allocator the released artifact therefore did not scale at all. Measured on an AMD Ryzen 7 PRO 6850U (8 cores / 16 threads, Linux) over the pinned corpus and the raw-blob lane, with the daemon pinned to six physical cores and the load generator to the other two, --batch-size 512 and a /dev/null sink; the daemon column is the median of three 30 s runs from scripts/perf/image-compare.sh and the single-core column comes from scripts/perf/baseline-eval.sh on the same two binaries:

Stock musl scales at 0.93x with routing: six cores deliver less than one, so the fan-out costs more than it returns. Changing allocator is worth ~14% single-threaded and 2.6-3.0x on the daemon, and that disproportion is the signature of allocator contention rather than per-event cost. Match counts are identical in every cell. jemalloc also reaches these figures on fewer cores (6.7-6.8 against 8.0), and halves rule load from 0.86 s to 0.49 s. Because none of this is visible to a native build, it needs scripts/perf/image-compare.sh rather than the harnesses above.

The witness audit (cargo run --release -p rsigma-eval --example witness_audit) shows 99.6% of the corpus carries a sound required-positive witness. The production CandidateIndex, measured directly over 10,000 events in each deterministic lane, returns a p95 of 0.29-3.86% of the 3,132 loaded rules: 0.38% on raw Windows and Cisco syslog, 3.74% on structured Windows, and 3.19% on Sysmon file events. This confirms the below-10% criterion with the actual index rather than the audit’s intentionally over-approximating simulation. Peak RSS for load + eval is ~113 MB. Sampling profiles taken before witness indexing attributed per-event time to event field lookup and hashing (~25-45%), std substring search and searcher setup (~13-30%), the condition and detection tree walk (~15%), case folding, and allocator traffic. Witness indexing removed most of that work rather than making it cheaper, so the remaining profile is due a re-capture before any further micro-optimization.

Match volume depends on flags because logsource routing is also a correctness filter: on the raw-blob lane the default configuration reports ~3 matches per event (mostly cross-product keyword false positives), while --logsource-routing drops that to ~0.02 per event.

The daemon matrix measures --include-event both with and without routing, including the match-heavy lane, because cloning the complete input into each result is material at ~3 matches per event and nearly free at ~0.02. Its checked-in correlation lane exercises event count, value count, value sum, and ordered temporal processing instead of relying on SigmaHQ, because the pinned corpus contains no correlation rules.

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. The rules are synthetic and exact-match-indexable, so the index prunes almost all of them per event; see Synthetic vs. representative workloads for why real corpora scale linearly instead.

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.