Ripgrep – A new command line search tool
Nice work.   But your story is incomplete if you don&#x27;t include comparison with icgrep (parabix.costar.sfu.ca).  Although icgrep is still an active research project, it is faster in many cases and has broader Unicode support (full Unicode level 1 of UTS #18, plus many level 2 features).  For example, try the &#x27;\N{SMIL(E|ING)}&#x27; search that finds lines containing emoji characters with SMILE or SMILING in their Unicode name.   icgrep also correctly applies Unicode character class intersection with expressions such as [\p{Greek}&amp;&amp;\p{Lu}], while ripgrep fails to meet UTS 18 level 1 requirements by interpreting &#x27;&amp;&amp;&#x27; as literal characters.<p>Nevertheless, we appreciate the challenge that ripgrep presents to our performance story.   We definitely see some cases in which rg achieves better performance taking advantage of fixed strings somewhere in the pattern.  We&#x27;ll have to work on that...   But for patterns based on Unicode classes (e.g., \p{Greek}, icgrep can be much faster, especially on large files.  (We are only focused on big data applications -- icgrep has significant dynamic compilation overhead).   It also does very well in cases involving alternations and ambiguity.<p>The icgrep performance story is based primarily on a new bitwise data parallel regular expression algorithm working off the Parabix transform representation of text.  See our ICA3PP 2015 or PACT 2014 papers.<p>It might be fair to say that icgrep is not yet polished enough for inclusion in your study.  I just added our first implementation of -r&#x2F;-R flags last night and we certainly haven&#x27;t yet handled .gitignore, etc. But if you want to understand the truth about regular expression performance, I think that the data point represented by icgrep (and its continuing development) needs to be included.