Rust FFI sped up C# hot-path scanning by 6.5x

At a glance

What this is: This is an engineering analysis of using Rust through FFI to accelerate sensitive-data regex scanning in a C# application, with the key finding that the Rust path materially outperformed the native C# implementation on the article’s test cases.

Why it matters: It matters because teams building DLP, data discovery, or content inspection workflows need to understand when cross-runtime integration improves throughput without breaking correctness, especially where scanning sits inside user-facing security controls.

By the numbers:

• For 1MB files at low match density, Island measured 8.25× faster processing, 5.2ms versus 42.9ms.
• 25MB files, iles, Island reported FFI performance that was 4-7.2× faster than the C# approach.
• 50MB files, iles, Island said FFI remained 3.3-6.5× faster than the C# baseline.

👉 Read Island's analysis of Rust FFI for faster C# regex scanning

Context

Sensitive-data scanning sits at the intersection of content processing, data protection, and user experience. When a security control runs inside a hot path, latency becomes a governance issue as much as an engineering one, because slow inspection can undermine adoption or push teams toward weaker controls. In this case, the primary question is how to keep text scanning fast enough to be usable without sacrificing match quality or maintainability.

The article is also a reminder that performance tuning in security tooling is often about runtime architecture, not just code style. FFI introduces a managed-to-native boundary, which changes how teams think about library choice, data marshalling, test coverage, and failure modes. For organisations that build scanning, filtering, or detection features into applications, the same design tension applies when the control must be both accurate and invisible to users.

Key questions

Q: How should teams decide whether to move regex scanning into a native runtime?

A: Teams should move regex scanning only when benchmarking shows a sustained gain on the workloads that matter, not just on synthetic tests. The decision should include boundary overhead, data conversion cost, test coverage, and operational support. If the native path improves throughput but creates fragile release management, the control may become harder to trust in production.

Q: Why do security controls inside hot paths need performance governance?

A: Controls inside hot paths affect whether inspection can run everywhere it is needed. If scanning is too slow, teams start narrowing coverage, batching work, or skipping checks under load. That turns performance into a control-quality issue, because the protection only exists where the system can afford to execute it.

Q: What breaks when managed and native code are joined too loosely?

A: Loose integration usually breaks observability, error handling, and release discipline. Teams may find that interface mismatches or marshalling problems show up only under load, which makes failures harder to diagnose. A thin, explicit contract with tests and version control is the best way to keep the optimisation safe.

Q: How can teams tell whether a faster scanning engine is actually better?

A: A faster engine is only better if it preserves match quality across the pattern types you rely on and remains maintainable under change. Teams should compare real file sizes, low and high match densities, and complex versus simple patterns. The right outcome is consistent control behaviour, not just a better benchmark number.

Technical breakdown

How FFI changes the execution path for regex scanning

Foreign Function Interface, or FFI, lets code in one language call functions compiled in another language. In this pattern, C# stays responsible for orchestration while Rust executes the regex work in a compiled DLL. That matters because the hot path moves from managed runtime overhead and library constraints into a faster native engine, but it also introduces data conversion costs, memory-safety considerations, and stricter interface design. The engineering challenge is not just calling Rust from C#, but keeping the boundary thin enough that the performance gain survives the handoff.

Practical implication: profile the call boundary, not just the target library, before deciding whether cross-language acceleration is worth the complexity.

Why regex set matching scales differently across workloads

RegexSet-style matching evaluates many patterns against the same input in a single pass, which is more efficient than testing each regex separately. That optimisation is valuable in data scanning, where dozens or hundreds of patterns may look for sensitive content such as identifiers, dates, or credentials. But the article shows that workload shape matters: simple expressions and a few alternations can favour the existing C# approach, while larger pattern sets and more complex expressions benefit from the Rust engine. In other words, algorithm choice and pattern complexity drive the real performance curve.

Practical implication: benchmark your own pattern mix and input sizes before standardising on one scanning strategy.

What testing and bindings tell you about maintainability

The article’s use of generated bindings and existing tests highlights a common integration pattern for performance-sensitive systems: preserve higher-level ergonomics while moving only the critical execution layer. Generated wrappers reduce glue-code drift, and unit tests provide confidence that the native engine preserves expected behaviour. Still, maintainability depends on disciplined interface contracts, error handling, and version control across the managed and native sides. The performance gain is only useful if the system remains observable, debuggable, and safe to evolve.

Practical implication: treat bindings, tests, and error codes as part of the control surface, not as implementation detail.

NHI Mgmt Group analysis

Performance engineering is now a security-control issue when scanning sits in the request path. Sensitive-data scanning is often treated as a backend optimisation problem, but in practice it governs whether inspection is applied consistently at all. If scanning is too slow, teams either accept user friction or narrow the scope of inspection, which weakens data protection. For application security and data security teams, throughput is part of control efficacy, not a separate concern.

Cross-runtime optimisation creates a different class of operational risk than pure application code. Moving logic into Rust via FFI can improve speed, but it also changes the trust boundary between managed and native components. That means security teams need stronger build controls, release discipline, and interface testing, because defects at the boundary can be harder to observe than defects inside a single runtime. The right frame is control assurance, not just performance tuning.

Data scanning workloads need pattern-aware governance, not one-size-fits-all tuning. The article shows that complex regex sets and long documents behave differently from short texts or simple keyword checks. That reinforces a broader point for DLP and content inspection programmes: detection logic should be benchmarked against real workloads before it is promoted into policy. The practical conclusion is that control design should reflect the actual pattern mix the business generates.

Rust-based hot paths are a useful example of where engineering decisions and data protection outcomes converge. The article’s main value is not that Rust is inherently better, but that sensitive-data detection depends on architectural fit. For security leaders, this is a reminder that the success of scanning controls often hinges on runtime efficiency, testability, and predictable failure behaviour. The practitioner takeaway is to review whether the control is fast enough to be used everywhere it is needed.

What this signals

Performance-sensitive inspection is increasingly part of security architecture, not just application engineering. When content scanning powers data loss prevention, secrets detection, or policy enforcement, the organisation is effectively deciding how much control can be executed at runtime without harming usability. That makes benchmark discipline and workload realism central to programme design.

Boundary-cost governance: the real risk is not only whether a control exists, but whether the managed-to-native boundary keeps it affordable enough to use everywhere. Teams that understand this can separate genuine architecture wins from one-off lab results, and that helps avoid policy exceptions that erode protection over time.

Where inspection logic underpins data security, the programme signal to watch is consistency under load. If performance varies sharply across file size or pattern complexity, the control may be behaving as a partial safeguard rather than a dependable one. For teams building detection or scanning features, that should trigger closer alignment with data protection policy and release governance.

For practitioners

• Benchmark the real scanning workload Measure your production pattern set, file sizes, and match density before changing runtime or regex engines. The relevant question is not which engine is fastest in theory, but which one stays efficient across your actual inspection mix.
• Isolate the hot path behind a thin interface Keep the managed layer small and make the native execution path explicit, with well-defined inputs, outputs, and error codes. This reduces boundary complexity and makes regressions easier to spot during release testing.
• Validate correctness with preserved test coverage Carry unit tests and fixture-based checks across both implementations so the faster path cannot silently change match semantics. For security scanning, false negatives are a control failure, not a cosmetic defect.
• Monitor fallback cases where C# may still win Document the inputs where simple regexes or low pattern counts are better served by the existing managed implementation. That lets teams route workloads intelligently instead of forcing every case through the same optimisation.

Key takeaways

• Security scanning performance is a control-design issue when the work happens in a user-facing hot path.
• Cross-runtime acceleration can deliver large gains, but only if boundary cost, test coverage, and workload mix are treated as first-class risks.
• The practical decision is not whether Rust is faster in isolation, but whether the faster path remains accurate, supportable, and consistent in production.

Key terms

• Foreign Function Interface: A foreign function interface lets code written in one programming language call functions compiled in another. It is used to combine strengths across runtimes, but it also introduces data-marshalling, error-handling, and boundary-management concerns that must be tested like any other production dependency.
• Hot Path: A hot path is the part of a system that executes so frequently or so critically that small inefficiencies become visible to users or operational teams. In security tooling, hot paths often include scanning, matching, filtering, and policy checks that must stay fast to remain effective.
• RegexSet: RegexSet is a pattern-matching approach that evaluates many regular expressions against a single input efficiently. Instead of testing each regex separately, it groups the work so the engine can identify which patterns match in one pass, which is useful for large-scale content scanning.

What's in the full article

Island's full post covers the implementation detail this post intentionally leaves for the source:

• The specific interoptopus-based binding pattern used to expose Rust methods to C#
• The ffi.rs and lib.rs code structure that the article only sketches here
• The benchmark methodology behind the 237-pattern test suite and file-size comparisons
• The cases where simple regexes still performed better in C# and why that matters for rollout

👉 Island's full post covers the benchmark details, wrapper code, and workload trade-offs

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need to connect identity governance to broader security and engineering decisions.