4 ms·
Interesting, it supports an n-gram indexer. ripgrep has had this planned for a few years now [1] but hasn't implemented it yet. For large codebases I've been
by comex 3y ago
Interesting, it supports an n-gram indexer. ripgrep has had this planned for a few years now [1] but hasn't implemented it yet. For large codebases I've been using csearch, but it has a lot of limitations.
Unfortunately... I just tried the indexer and it's extremely slow on my machine. It took 86 seconds to index a Linux kernel tree, while csearch's cindex tool took 8 seconds.
[1] https://github.com/BurntSushi/ripgrep/issues/1497 https://github.com/BurntSushi/ripgrep/issues/1497
- dtgriscom 3y agoThat's close to a gig of disk reads; I trust you didn't try ugrep first and then cindex second, without taking into account caching.
- comex 3y agoI ran both multiple times, alternating (and making sure to clean out the indexes in between). Results were reasonably consistent across runs.
- jgalt212 3y agoIf you're gonna go the csearch route, you should also consider hound. I use it many times per day. https://github.com/hound-search/hound https://github.com/hound-search/hound
- bishfish 3y agoIt creates per-directory index files on its first run. ugrep-indexer is also labeled as beta. A couple of relevant quotes from its GitHub site: “Indexing adds a hidden index file ._UG#_Store to each directory indexed.” “Re-indexing is incremental, so it will not take as much time as the initial indexing process.”