There are actually several tricks at the "string algorithm" level. I didn't invent any of them, but no other search tool combines all of them AFAIK. They are:
* Heuristic for choosing the skip character in boyer moore. (Pick rare bytes.)
* Roll UTF-8 decoding into the regex automaton.
* Use SIMD for multiple string literal search. (This is an unpublished algorithm from Intel's Hyperscan project.)
There was also significant work required for scaling glob matching. Some popular repositories have gitignore files with over 3000 rules.
These are important because ripgrep isn't just for searching code repositories. It should be able to do most things that grep can do, but faster. (The smarter UTF-8 handling is particularly beneficial when searching non-ASCII text.)
Within the context of this thread though, and as someone who has written a linear time suffix array algorithm, the suffix array isn't particularly well suited to the problem of code search. Its constant factors are just too high. Generating an index would take a long time. (Although I haven't read the OP yet.)
> some system call tricks for reading files as quickly as possible.
ripgrep does two different types of searches. One uses memory maps. The other uses standard `read` calls. The latter is actually faster on Linux when searching code repositories. So no real tricks there. :-)