In an attempt to remove some of my ignorance, I tried this:
(MBA, M1)
time rg Query src > /tmp/junk.rg
rg Query src > /tmp/junk.rg 0.01s user 0.04s system 156% cpu 0.037 total
time pt Query src > /tmp/junk.pt
pt Query src > /tmp/junk.pt 1.44s user 10.80s system 220% cpu 5.545 total
time ag Query src > /tmp/junk.ag
ag Query src > /tmp/junk.ag 4.32s user 9.82s system 204% cpu 6.918 total
ls -l /tmp/junk\*
-rw-r--r-- 1 sramam wheel 16492080 Nov 10 16:05 /tmp/junk.ag
-rw-r--r-- 1 sramam wheel 16492080 Nov 10 16:04 /tmp/junk.pt
-rw-r--r-- 1 sramam wheel 27477 Nov 10 16:04 /tmp/junk.rg
This is a TypeScript module, turns out ripgrep correctly ignores the sourcemaps for the improved performance. I like tools that are smart by default.
I think rg isn’t ignoring sourcemaps to be fast. It tries to ignore based on .gitignore and similar files, but maybe the sorcemaps are ignored for being binary.
I thought so too. The documentation for all state they honor .gitignore. In my case, the compiled code is committed.
My query was for a generic term "src" - so that likely trapped the file-path embedded within the long lines of a source-map. Hence the massive file-size difference.
The main goal of respecting gitignore is generally to decrease noise in search results. But, this does of course also have the effect of improving performance in a lot of cases.
(EDIT: formatting)