Notifications
Clear all
Topic starter
02/08/2026 12:00 pm
TL;DR: Moving a sensitive-data text-scanning hot path from native C# regex to a Rust-based FFI implementation produced a 3-10x speedup, with 4.9-8.25x gains on 1-10MB files and 3.3-6.5x on 25-50MB files, according to Island. The architectural lesson is that performance bottlenecks in security-adjacent scanning often sit at runtime boundaries, not just in the regex engine itself.
NHIMG editorial — based on content published by Island: Crossing Runtimes: Accelerating C# with Rust and Cursor Engineering
By the numbers:
- For 1MB files at low match density, Island measured 8.25× faster processing, 5.2ms versus 42.9ms.
- For 25MB files, Island reported FFI performance that was 4-7.2× faster than the C# approach.
- For 50MB files, Island said FFI remained 3.3-6.5× faster than the C# baseline.
Questions worth separating out
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.
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.
Q: What breaks when managed and native code are joined too loosely?
A: Loose integration usually breaks observability, error handling, and release discipline.
Practitioner guidance
- Benchmark the real scanning workload Measure your production pattern set, file sizes, and match density before changing runtime or regex engines.
- 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.
- 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.
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
👉 Read Island's analysis of Rust FFI for faster C# regex scanning →
Rust FFI for regex scanning: what it changes for secure data processing?
Explore further
02/08/2026 1:07 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Rust FFI sped up C# hot-path scanning by 6.5x
