There's probably someone who posts this comment every time this article comes up, but:<p><pre><code> #![feature(test)]
extern crate regex;
extern crate test;
use regex::Regex;
pub fn check(pattern: &Regex, input: &str) -> bool {
pattern.is_match(input)
}
#[cfg(test)]
mod tests {
use super::*;
use test::Bencher;
#[bench]
fn bench_check(b: &mut Bencher) {
let n = 29;
let pattern = Regex::new(&format!("{}{}", "a?".repeat(n), "a".repeat(n))).unwrap();
let input = "a".repeat(n);
b.iter(|| check(&pattern, &input));
}
}
</code></pre>
And then:<p><pre><code> $ cat rust-toolchain
nightly-2018-02-09
$ cargo bench
Compiling void v1.0.2
Compiling lazy_static v1.0.0
Compiling regex-syntax v0.4.2
Compiling libc v0.2.36
Compiling utf8-ranges v1.0.0
Compiling unreachable v1.0.0
Compiling thread_local v0.3.5
Compiling memchr v2.0.1
Compiling aho-corasick v0.6.4
Compiling regex v0.2.6
Compiling regexps v0.1.0 (file:///home/twic/Code/Regexps)
Finished release [optimized] target(s) in 20.11 secs
Running target/release/deps/regexps-9c084e63d7d31ac3
running 1 test
test tests::bench_check ... bench: 212 ns/iter (+/- 8)
test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 0 filtered out
</code></pre>
Rust's standard regex library isn't the fastest in the world, and the lack of backtracking can be limiting, but it is highly optimised for Rust's main use case of posting showoff comments on Hacker News.<p>I also tried this in Java (OpenJDK 1.8.0_161-b14), and it took about 24 seconds per iteration at 29 characters.
This is an excellent read. I would suggest reading this also (maybe even before), as it provides one of the simplest (incomplete, but still useful) regex implementations you'll ever see: <a href="https://www.cs.princeton.edu/courses/archive/spr09/cos333/beautiful.html" rel="nofollow">https://www.cs.princeton.edu/courses/archive/spr09/cos333/be...</a>
It suffers from the problems remedied by the original submission (backtracking instead of DFA), but the code is shorter and simpler. They're great to compare.
The biggest gap in the references/history section is the failure to mention V. Glushkov, whose NFA construction has much appeal and certainly predates Thompsons'. Reading the references, one might also draw the conclusion that regex implementation almost ceased between 1968 and 2007.<p>In our experience, regex matching <i>can</i> be simple and fast, but only sometimes. RE2's approach is straightforward but naive; we built a considerably faster (on some metrics) and more scalable system in Hyperscan. The cost of this turned out to considerable complexity - and there are still many regexes and inputs that don't perform particularly well in either system.
I thought this was going to be about compiling regular expressions, which is how CL-PPCRE (<a href="https://edicl.github.io/cl-ppcre/" rel="nofollow">https://edicl.github.io/cl-ppcre/</a>) manages to be faster than C. Better algorithms beat compilation, though.
Slightly off-topic, <i>derivatives of regular expressions</i> is fun and interesting:<p><a href="https://en.wikipedia.org/wiki/Brzozowski_derivative" rel="nofollow">https://en.wikipedia.org/wiki/Brzozowski_derivative</a><p><a href="http://lambda-the-ultimate.org/node/2293/" rel="nofollow">http://lambda-the-ultimate.org/node/2293/</a>
The comments from the original post[1] of this are still quite relevant. I feel like I've seen this link posted here several times (much more recently than 2009), but I can't find the links.<p><pre><code> [1]: https://news.ycombinator.com/item?id=466845</code></pre>
There are modules that implement the Thompson's algorithm
For Python: <a href="https://github.com/xysun/regex" rel="nofollow">https://github.com/xysun/regex</a>
The vim text editor actually can use the NFA regular expression engine [1] for some searches. I'm not sure if that's an option for some of the languages mentioned in the article.<p>[1] <a href="http://vimhelp.appspot.com/options.txt.html#%27regexpengine%27" rel="nofollow">http://vimhelp.appspot.com/options.txt.html#%27regexpengine%...</a>
This should be labeled (2007) and has been on HN several times before. It's a good article.<p>The article (and the wikipedia) say Thomson put regexps into a version of QED for CTSS, but CTSS was only used at MIT. He must have traveled between MIT and Bell labs as part of the Multics project. The CTSS reference is pretty obscure.
Yes, I know. But regex for everything is bad. What about Parsec? Anyone? <a href="http://book.realworldhaskell.org/read/using-parsec.html" rel="nofollow">http://book.realworldhaskell.org/read/using-parsec.html</a>