Is this speed competitive with tools like the silver searcher (`ag`) or is the focus here on color?
Here's an excellent write-up on how it works, benchmarks, etc.: https://blog.burntsushi.net/ripgrep/
A good place to start would be this: why GNU grep is fast[1] - Starting with the Boyer-Moore string search algorithm and reading through the optimizations done in GNU grep.
p.s. there's an implementation of Boyer-Moore hiding in Go's standard library.
[1] https://lists.freebsd.org/pipermail/freebsd-current/2010-Aug...
In Go-land, you should be able to replace uses of memchr with IndexByte[1], which should be implemented in Assembly on most platforms.
Of course, for any of this to have a big impact, you'll want to take Mike Haertel's advice on avoiding line breaking and stop using bufio.Scanner. :-)
There are a couple of places I wish I would have done better. Using bufio.Scanner actually bothers me a lot. Also in the Read() method it reads everything from all readers into a buffer instead of pulling what it needs to check.
Thanks for suggestions :)
I suppose in that sense it does aim to be fast. Fast for the human to parse.
My desktop is running ubuntu-18.04, is an i5-3570, and has a fairly quick intel SSD.
Running "blush -R -i FunctionName ." takes 15.090 seconds and finds two files.
Running "ag -i FunctionName", finds one file, missing one in .clang-format.
Running "ag -i -u FunctionName", finds two files and makes 0.64 seconds.
So somewhere around 20-25x faster.
I know ripgrep has a ton of fantastic optimizations by Burntsushi.
You might wanna check it out...before making such statements.
Plus the next time you make sweeping generalisations about the reading comprehension abilities of HN it is probably worth remembering that this is an international community and thus English isn't going to be everyone's first language.