
Ripgrep is faster (2016) - tosh
https://blog.burntsushi.net/ripgrep/
======
tux1968
Not sure if this is coincidence or even if this was already mentioned on HG,
but Ripgrep had a release yesterday with a few new features.

[https://github.com/BurntSushi/ripgrep/releases/tag/0.10.0](https://github.com/BurntSushi/ripgrep/releases/tag/0.10.0)

~~~
StavrosK
Fantastic, I use RipGrep every day and just noticed I was on 0.4.0. I wish
they had a PPA or an easier way for me to have it update automatically...

~~~
dguaraglia
If you don’t mind the wait to compile rustc from source once (only for tools
written in rust, of course), linuxbrew is a pretty neat way of keeping tools
that aren’t directly on your distro’s repos up-to-date. Nix is another option.

~~~
StavrosK
Oh that's very interesting, thank you! Do you know if Nix works well with
Ubuntu? I'd love to use it but I didn't think it would play well with apt.

~~~
yjftsjthsd-h
It stands separate from apt, yes.

------
agumonkey
related
[https://blog.burntsushi.net/transducers/](https://blog.burntsushi.net/transducers/)

------
aidenn0
Interestingly enough a friend of mine kept trying to get me to use ag, since
he always saw me doing relatively long "find" commands. A discussion about
perfomance, ease of use, &c. later and I wrote an ag clone in shell, called
"the copper searcher." Performance is similar between the two, I think I got
most of the major features implemented.

Also note that if you still have UUCP infrastructure, the name "cu" will
collide with an already installed program.

[https://github.com/jasom/the-copper-searcher](https://github.com/jasom/the-
copper-searcher)

~~~
burntsushi
Neat! That's definitely better than some of the other shell clones I've seen,
in that it makes an attempt to filter out files based on .gitignore. But it
looks like it still gets some .gitignore stuff wrong. It's hard to handle
.gitignore correctly in a simple way.

In some simple tests on my Linux checkout, it is about an order of magnitude
slower than ripgrep though. It looks like a good chunk of time is spent in
gitignore filtering?

I don't think it has multi-line search, which is something I've learned that
ag users happen to love, which is why it's in the most recent release of
ripgrep. :-)

~~~
aidenn0
Yeah, this was just a 1 afternoon project, and the .gitignore syntax is more
complicated than I first thought.

------
jwilk
See also:
[https://news.ycombinator.com/item?id=12564442](https://news.ycombinator.com/item?id=12564442)

------
scarejunba
This is a truly fantastic product. I didn't think ag could be improved but
somehow ripgrep does it. Well done.

------
holstvoogd
Searching through my 'projects' directory, piping all output to wc so my
terminal doesn't become a factor, it is about 16 times faster than ack; 26
times when using the gitignore filtering. It is using ~7 times more CPU to do
so.

~~~
gpm
Is there a reason that you prefer wc over /dev/null?

~~~
ploxiln
to check the outputs are roughly the same?

------
nickcw
Since practically everything I work on is in a git repository, I use git grep
a lot. I haven't found it wanting in speed.

Ripgrep does have some neat advanced features though...

~~~
bluetech
One reason I still use git grep is this: I have some minified .js files in the
repository, which I don't want to be included in grep results. So I mark the
files as binary in gitattributes, then git grep just says "Binary file foo
matches".

~~~
burntsushi
For ripgrep, you can achieve this via a custom ignore file, e.g., `echo
'*.min.js' > .ignore`.

Another approach I've seen people take is to put `-M300` in your ripgrep
config file, and then any super long lines are automatically omitted from
output.

~~~
h1d
I've seen the few posts deciding to use .ignore as the file name but I hope
this won't be a mistake in choosing the right name without enough discussion.
Even for users it's hard to figure what the file is for.

I consider .grepignore to be more comprehensible.

~~~
burntsushi
You can also use .rgignore.

