regex

https://github.com/rust-lang/regex/pull/91 I'm guessing, probably more specifically https://github.com/rust-lang/regex/issues/21 The bench changes are very impressive (beware though, new benches have been added as smaller ones had gotten too fast to be of much interest) It seems regex! (the one provided in the library, not the one used by TFA's benchmark) has suffered from some performance regressions[0] though many of its usage would benefit from using the dynamic Regex::new instead., [0] https://github.com/rust-lang/regex/issues/95

This uses a pure-Rust regex engine[1] by Andrew Gallant. [1]: https://github.com/rust-lang/regex

Well, I'm not going to remove it. But I will see if I can find some time to improve it in the next few days. I've been meaning to cycle back around. Of course, fixes from somebody who's actually a Rust expert would have been preferred :-) The reason it still uses the alternate pcre is because this still hasn't been fixed: https://github.com/rust-lang/regex/issues/28 I would love to get rid of that nastiness.

I was still pretty surprised that `regex` was getting killed. It turns out, I think, that `\w+` in Rust is Unicode friendly, but it's not in Nim. In cases where most matches fail, checking the full spectrum of Unicode "word" characters becomes pretty expensive (although it is at least doing a binary search on contiguous ranges of characters: https://github.com/rust-lang/regex/blob/master/src/vm.rs#L23...). When I switched `\w+` to `[a-zA-Z0-9_]+` in the Rust program, I saw a ~60% performance increase. > and libregex is optimized to avoid exponential blowup on pathological regexes. It's missing a fallback to the backtracking algorithm at present. Maybe. RE2/C++ doesn't do any backtracking AFAIK, but it appears near the top of any benchmark I think.