PCRE2 mode rg -P is consistently faster than rg

[LeoniePhiline]

Going through https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#why-does-ripgrep-get-slower-when-i-enable-pcre2-regexes, I tried the example:

$ curl -O 'https://burntsushi.net/stuff/subtitles2016-sample.gz'
$ gzip -d subtitles2016-sample
$ md5sum subtitles2016-sample
e3cb796a20bbc602fbfd6bb43bda45f5   subtitles2016-sample
time rg '^\w{42}$' subtitles2016-sample
time rg -P '^\w{42}$' subtitles2016-sample

On this laptop, time rg '^\w{42}$' subtitles2016-sample takes about 1.33s - 1.35s, while time rg -P '^\w{42}$' subtitles2016-sample, which is expected to be slower, takes only 1.14s - 1.16s.

Here some hopefully more reliable hyperfine results:

$ hyperfine  "rg '^\w{42}$' subtitles2016-sample" "rg -P '^\w{42}$' subtitles2016-sample"
Benchmark 1: rg '^\w{42}$' subtitles2016-sample
  Time (mean ± σ):      1.476 s ±  0.039 s    [User: 1.444 s, System: 0.032 s]
  Range (min … max):    1.400 s …  1.538 s    10 runs
 
Benchmark 2: rg -P '^\w{42}$' subtitles2016-sample
  Time (mean ± σ):      1.213 s ±  0.006 s    [User: 1.179 s, System: 0.033 s]
  Range (min … max):    1.202 s …  1.223 s    10 runs
 
Summary
  rg -P '^\w{42}$' subtitles2016-sample ran
    1.22 ± 0.03 times faster than rg '^\w{42}$' subtitles2016-sample

$ hyperfine "rg -P '^\w{42}$' subtitles2016-sample --no-encoding"
Benchmark 1: rg -P '^\w{42}$' subtitles2016-sample --no-encoding
  Time (mean ± σ):      1.161 s ±  0.011 s    [User: 1.130 s, System: 0.030 s]
  Range (min … max):    1.141 s …  1.174 s    10 runs

$ hyperfine "rg -U '^\w{42}$' subtitles2016-sample" "rg -P -U '^\w{42}$' subtitles2016-sample"
Benchmark 1: rg -U '^\w{42}$' subtitles2016-sample
  Time (mean ± σ):      1.447 s ±  0.048 s    [User: 1.411 s, System: 0.036 s]
  Range (min … max):    1.362 s …  1.487 s    10 runs
 
Benchmark 2: rg -P -U '^\w{42}$' subtitles2016-sample
  Time (mean ± σ):     942.7 ms ±   6.2 ms    [User: 912.8 ms, System: 29.7 ms]
  Range (min … max):   936.6 ms … 953.4 ms    10 runs
 
Summary
  rg -P -U '^\w{42}$' subtitles2016-sample ran
    1.54 ± 0.05 times faster than rg -U '^\w{42}$' subtitles2016-sample

Is this a performance regression of the ripgrep or regex crates?

$ rg --version          
ripgrep 14.1.0

features:-simd-accel,+pcre2
simd(compile):+SSE2,-SSSE3,-AVX2
simd(runtime):+SSE2,+SSSE3,+AVX2

PCRE2 10.42 is available (JIT is available)

[BurntSushi]

On my i9-12900K, there's no meaningful regression in ripgrep's default regex engine for this benchmark:

$ time static-rg-14.1.0 '^\w{42}$' subtitles2016-sample
21225780:EverymajordevelopmentinthehistoryofAmerica

real    1.205
user    1.165
sys     0.040
maxmem  933 MB
faults  0

$ time static-rg-13.0.0 '^\w{42}$' subtitles2016-sample
21225780:EverymajordevelopmentinthehistoryofAmerica

real    1.220
user    1.179
sys     0.040
maxmem  944 MB
faults  0

$ time static-rg-11.0.2 '^\w{42}$' subtitles2016-sample
21225780:EverymajordevelopmentinthehistoryofAmerica

real    1.229
user    1.195
sys     0.033
maxmem  941 MB
faults  0

PCRE2 has actually gotten a little faster (and is indeed faster than ripgrep's default regex engine here):

$ static-rg-14.1.0 --pcre2-version
PCRE2 10.42 is available (JIT is available)
$ static-rg-13.0.0 --pcre2-version
PCRE2 10.32 is available
JIT is available
$ static-rg-11.0.2 --pcre2-version
PCRE2 10.32 is available
JIT is available

$ time static-rg-14.1.0 -P '^\w{42}$' subtitles2016-sample
21225780:EverymajordevelopmentinthehistoryofAmerica

real    0.923
user    0.876
sys     0.047
maxmem  926 MB
faults  0
$ time static-rg-13.0.0 -P '^\w{42}$' subtitles2016-sample
21225780:EverymajordevelopmentinthehistoryofAmerica

real    1.123
user    1.099
sys     0.023
maxmem  925 MB
faults  0
$ time static-rg-11.0.2 -P '^\w{42}$' subtitles2016-sample
21225780:EverymajordevelopmentinthehistoryofAmerica

real    1.116
user    1.075
sys     0.040
maxmem  925 MB
faults  0

But if I hop over to my i7-6900K machine (which is due to be decommissioned Real Soon Now), which is the machine where I likely ran the original benchmarks, then we see a different story here. First, ripgrep's default regex engine:

$ time static-rg-14.1.0 '^\w{42}$' subtitles2016-sample
21225780:EverymajordevelopmentinthehistoryofAmerica

real    1.621
user    1.593
sys     0.027
maxmem  931 MB
faults  0

$ time static-rg-13.0.0 '^\w{42}$' subtitles2016-sample
21225780:EverymajordevelopmentinthehistoryofAmerica

real    1.703
user    1.675
sys     0.027
maxmem  943 MB
faults  0

$ time static-rg-11.0.2 '^\w{42}$' subtitles2016-sample
21225780:EverymajordevelopmentinthehistoryofAmerica

real    1.699
user    1.664
sys     0.033
maxmem  940 MB
faults  0

There's a little variation here, but overall about the same.

$ time static-rg-14.1.0 -P '^\w{42}$' subtitles2016-sample
21225780:EverymajordevelopmentinthehistoryofAmerica

real    1.766
user    1.731
sys     0.033
maxmem  924 MB
faults  0

$ time static-rg-13.0.0 -P '^\w{42}$' subtitles2016-sample
21225780:EverymajordevelopmentinthehistoryofAmerica

real    1.972
user    1.937
sys     0.033
maxmem  925 MB
faults  0

$ time static-rg-11.0.2 -P '^\w{42}$' subtitles2016-sample
21225780:EverymajordevelopmentinthehistoryofAmerica

real    2.035
user    1.997
sys     0.037
maxmem  922 MB
faults  0

So PCRE2 got a nice boost here when I upgraded it from 10.32 to 10.42 in the ripgrep 14 release. It is still not as slow as what was seen in the linked FAQ, but one thing I didn't control for here is the Rust compiler. I built all of the static-rg-* binaries above with a very recent Rust compiler. So changes in inlining, for example, might have a big impact here.

Also, PCRE2 doesn't need transcoding any more as of the ripgrep 14 release because of new APIs they added:

$ static-rg-14.1.0 -P '^\w{42}$' subtitles2016-sample --trace 2>&1 | rg transcoding
$ static-rg-13.0.0 -P '^\w{42}$' subtitles2016-sample --trace 2>&1 | rg transcoding
TRACE|grep_searcher::searcher|crates/searcher/src/searcher/mod.rs:755: slice reader: needs transcoding, using generic reader

This is also likely contributing to the improved speed.

[LeoniePhiline]

thank you very much for your response!

Great to see pcre2 having gotten faster.

Side question: Do you think you will ever find time and motivation to expose pcre2 substitution? (I really hope I am not coming across as if I was trying to push you! My goal is only to make a decision based on your plans.) I had wanted to extend fastmod with rust-pcre2 to run replacements with opt-in lookaround-enabled searches (just like rg -P).
facebookincubator/fastmod#49

fastmod is already using your grep lib and the searcher / matcher API, so I thought implementing a pcre2 mode for fastmod would be easy. As it turned out, though, substitution is not exposed, and it looked like you are probably never going to implement the bindings.

Is my impression correct? If yes, then I'd go forward trying to integrate fancy-regex (adding a --fancy flag rather than a --pcre2 flag), but if you had anyway been considering implementing the pcre2-sys & rust-pcre2 (& grep::pcre2) bindings to make replacement possible, then I'd drop the fancy-regex related plans and pivot back to pcre2.

[BurntSushi]

If by rust-pcre2 you mean the pcre2 crate, then I'm generally open to exposing whatever is in the underlying PCRE2 crate. I don't personally have any plans to work on such a thing (and I'll never expose it in ripgrep), but if someone wanted to submit a non-invasive patch for it, I could be convinced.

[LeoniePhiline]

Thanks for your response!

Yes, the pcre2 crate, which is found in https://github.com/BurntSushi/rust-pcre2.

I have little experience with C bindings, but I’ll give this a good look. Maybe I can PR the substitution feature into the crate.

I am aware that ripgrep won’t ever gain replacement features beyond the currently available non-in-place substitution, and that is perfectly okay. I am only looking at bringing PCRE2 support into fastmod (as an interested user of the tool, not affiliated with facebook in any way), which has switched to the grep crate to benefit from your fantastic optimizations.