ripgrep combines the usability of The Silver Searcher with the raw speed of grep https://rebizzz.github.io/git-on-github/ripgrep.git/atom 2026-08-04T14:00:08+00:00 2026-08-04T14:00:08+00:00 Andrew Gallant jamslam@gmail.com 2026-08-04T14:00:08+00:00 urn:sha1:3fce3b5bb0236da2df6d99672afb8a719642eca7 2026-08-04T13:59:57+00:00 Andrew Gallant jamslam@gmail.com 2026-08-04T13:59:57+00:00 urn:sha1:5055264ae021b5d0e01e55f723622d638ea877f0 2026-08-04T13:46:53+00:00 Andrew Gallant jamslam@gmail.com 2026-08-04T11:46:42+00:00 urn:sha1:020687a77d13146923333f0beb274eeabd54a270 When do matching inside of `ignore` or `globset`, we sometimes need a reusable mutable scratch space for matching. To do this, we use a `Pool` abstraction from `regex-automata` to do this heavy lifting for us. It turns out that this can be a limiting factor in some scenarios when gitignore matching dominates. For example, in my checkout of the Chromium repository: ``` $ hyperfine 'rg-master -j32 --files' 'rg-bigger-pool -j32 --files' 'rg-master -j32 --files --no-ignore' Benchmark 1: rg-master -j32 --files Time (mean ± σ): 156.3 ms ± 5.5 ms [User: 2356.4 ms, System: 380.8 ms] Range (min … max): 147.6 ms … 164.5 ms 19 runs Benchmark 2: rg-bigger-pool -j32 --files Time (mean ± σ): 131.6 ms ± 2.1 ms [User: 1628.2 ms, System: 310.1 ms] Range (min … max): 128.8 ms … 136.3 ms 22 runs Benchmark 3: rg-master -j32 --files --no-ignore Time (mean ± σ): 107.4 ms ± 1.0 ms [User: 664.7 ms, System: 304.7 ms] Range (min … max): 104.9 ms … 109.6 ms 28 runs Summary rg-master -j32 --files --no-ignore ran 1.22 ± 0.02 times faster than rg-bigger-pool -j32 --files 1.45 ± 0.05 times faster than rg-master -j32 --files ``` The `--no-ignore` benchmark is our baseline. It doesn't process gitignore files, so it's quite a bit faster. But with this change, processing gitignore files gets faster than what is currently on master. Specifically, re-running the above without the baseline: ``` $ hyperfine 'rg-master -j32 --files' 'rg-bigger-pool -j32 --files' Benchmark 1: rg-master -j32 --files Time (mean ± σ): 154.1 ms ± 5.1 ms [User: 2287.4 ms, System: 378.2 ms] Range (min … max): 144.1 ms … 163.9 ms 19 runs Benchmark 2: rg-bigger-pool -j32 --files Time (mean ± σ): 131.7 ms ± 2.1 ms [User: 1618.6 ms, System: 314.1 ms] Range (min … max): 128.4 ms … 135.3 ms 22 runs Summary rg-bigger-pool -j32 --files ran 1.17 ± 0.04 times faster than rg-master -j32 --files ``` I've used `-j32` here because this change is best observed as improving the *scaling* properties. (And my system has 32 cores, so it's the best case scenario.) If we just let ripgrep use its default thread heuristic (which caps itself at a lower value), then the improvement here is a bit more modest: ``` $ hyperfine 'rg-master --files' 'rg-bigger-pool --files' Benchmark 1: rg-master --files Time (mean ± σ): 150.0 ms ± 8.5 ms [User: 1139.6 ms, System: 237.7 ms] Range (min … max): 131.1 ms … 162.4 ms 22 runs Benchmark 2: rg-bigger-pool --files Time (mean ± σ): 136.0 ms ± 12.1 ms [User: 1034.4 ms, System: 236.0 ms] Range (min … max): 117.7 ms … 157.6 ms 22 runs Summary rg-bigger-pool --files ran 1.10 ± 0.12 times faster than rg-master --files ``` This improves scaling because the underlying change here now uses a cache line for each available thread instead of limiting itself to a fixed value of `8`. The cost is that ripgrep may use a bit more memory storing cached values per thread. 2026-08-03T11:38:57+00:00 Andrew Gallant jamslam@gmail.com 2026-08-03T11:28:10+00:00 urn:sha1:7525479a9576f1ca4c2d04339d78e47ff5ae9b05 It looks like the location of executables is changing in Cargo's test runner, so use the blessed way of discovering an executable. That is, for ripgrep, consult the `CARGO_BIN_EXE_rg` environment variable. 2026-08-03T11:15:23+00:00 Andrew Gallant jamslam@gmail.com 2026-08-03T11:15:23+00:00 urn:sha1:5ed408e17eccfc59bcec48f584feece902873e54 2026-07-29T15:00:03+00:00 jif jif@openai.com 2026-07-29T15:00:03+00:00 urn:sha1:435f59fc4b43af3ab32f34d53fa34978f393fe52 When parallelism isn't used (e.g., when sorting results), then it's possible in some cases for the `ignore` crate to still try and load gitignore files inside of directories that are never descended into. This can occur when `--max-depth` is used, or even just when a directory is skipped for some other reason. Fixes #2565, PR #3496 2026-07-28T22:57:17+00:00 Kobi Hikri kobi.hikri@gmail.com 2026-07-28T22:57:17+00:00 urn:sha1:dffd776a737dc19a48b758dd6a621de113794121 PR #3495 2026-07-24T12:03:07+00:00 Andrew Gallant jamslam@gmail.com 2026-07-24T11:38:17+00:00 urn:sha1:f9c05a949d1a0dc8e16dee28ca9605d38611faeb 2026-07-22T15:51:56+00:00 Andrew Gallant jamslam@gmail.com 2026-07-22T14:45:02+00:00 urn:sha1:8372866810a1f2a647d11d7780984d4402a5c1e9 This gives us some room to actually start writing out some index operations. 2026-07-22T15:51:56+00:00 Andrew Gallant jamslam@gmail.com 2026-07-20T17:52:04+00:00 urn:sha1:d99ac34406f82c03c3938c222f1786495c845034