There are some inaccuracies in this comment.

Firstly, that link shows PCRE2 and Rust's regex engine are neck-and-neck. And that's including the fact that the benchmark contains a regex that is hard for DFA engines but contains no regexes that are hard for backtrackers. (I lodged this criticism against the author of the benchmark before they published it.)

Secondly, Rust's regex crate is heavily inspired by RE2. They support roughly the same features. So if RE2 is limited, then so is Rust's regex library.

Rust's regex library tends to do a little better than RE2 in a wide variety of common use cases because of aggressive literal optimizations. But if you mask those out, performance will be comparable. (Also, if you benchmarked captures, I bet RE2 would win handedly. Rust's regex library needs some work in that area.)

I tested it also for inclusion into cperl to replace the horrible old spencer regex code with longjmp for logical control and double parsing, and came to my conclusions. Rust's will get better eventually, but PCRE2 also gets better every week. That time PCRE2 was a bit faster, and supported more features. And it has a JIT. Only Hyperscan, PCRE2 and sregex have a JIT.

I haven't checked Rust's feature list, sorry. I ruled it out for serious usage very early, and it's still evolving.

Captures are very important for us. Same as UTF8. There was once the idea to switch to a limited engine like RE2 after the first scan of the regex when it doesn't do backtracking. But then I would switch to Hyperscan instead, which has the best compiler, besides having a very good SIMD optimized runtime.

Sorry, but there are still inaccuracies in your comments.

Hyperscan doesn't have a JIT. PCRE2 and sregex are not the only ones with a JIT. For example, PyPy's regex engine is JITed and so is v8's. The existence of Hyperscan (and Rust's regex engine) should show that a JIT is not necessary for high performance.

(Disclaimer: I am the author of Rust's regex library.)

I would qualify the Hyperscan engine as "JIT". Not a traditional, but practically. It's dynamic architecture-optimized superfast bytecode, but much more native than a normal platform-independent bytecode. Look e.g. at the nfa limex interpreter/runtime. It uses intel opcodes dynamically for various SIMD features, simd128,256,384,512.

Yes, pypy and v8 also have a jit, but not usable as library. ruby extracted their regex library, so I could use it also. pypy and v8 did not.

This summary was "very easy", because it is wrong. This assessment is unfair to RE2, and we're comparing to RE2 because it's the only one of these that can do multiple regex. Both Hyperscan and RE2 throw a good deal of regex under the bus in order to get multiple regex support, performance and/or streaming capability.

Rust's regex library has had support for regex sets for quite some time, and it's based on the same "tricks" that RE2 uses: https://docs.rs/regex/0.2.2/regex/struct.RegexSet.html

Oops. We're out of date in our thinking then. If the implementation is similar to re2, you'll probably see similar performance, although I hear good things about your small group literal matcher. :-)

:P Yeah, I would expect performance characteristics to be very similar to RE2! I actually think RegexSet disables literal optimizations in more cases than the standard regex, but it's been a while since I've touched that.