3 ms·

ripgrep always stroke me like the "industrial strength faberge egg" of Knuth/McIlroy fame [1] Yes it's an impressive achievement to make it that fast, but you

by nn3 5y ago

ripgrep always stroke me like the "industrial strength faberge egg" of Knuth/McIlroy fame [1] Yes it's an impressive achievement to make it that fast, but you could get the same or better performance by just using an index to search. I've been using GNU id-utils [2] for a long time, that is using an index, and it gets comparable performance for a fraction of the source code and brain power, and likely energy use too. [1] http://blobthescientist.blogspot.com/2017/10/knuth.html http://blobthescientist.blogspot.com/2017/10/knuth.html [2] https://www.gnu.org/software/idutils/ https://www.gnu.org/software/idutils/

burntsushi 5y ago
The comparison doesn't really make much sense IMO. Searching with and without indexing is targeting two very different use cases. I wanted to try idutils and see if it suffered from pitfalls (like if the indexing scanner didn't grab a token) or how it handled regexes. But I couldn't get it compiled using these commands[1]. It failed with: gcc -DHAVE_CONFIG_H -I. -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -MT fseterr.o -MD -MP -MF .deps/fseterr.Tpo -c -o fseterr.o fseterr.c fseterr.c: In function 'fseterr': fseterr.c:74:3: error: #error "Please port gnulib fseterr.c to your platform! Look at the definitions of ferror and clearerr on your system, then report this to bug-gnulib." 74 | #error "Please port gnulib fseterr.c to your platform! Look at the definitions of ferror and clearerr on your system, then report this to bug-gnulib." | ^~~~~ make[3]: *** [Makefile:1590: fseterr.o] Error 1 So I can't even easily get idutils to try it, but suspicion is that it misses some key use cases. And from what I can tell, its index doesn't auto-update, so you now have to use your brain power to remember to update the index. (Or figure out how to automate it.) ripgrep is commonly used in source code repos, where you might be editing code or checking out different branches all the time. An indexing tool in that scenario without excellent automatic updates is a non-starter. [1] - https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=idutils https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=iduti...

by nn3 5y ago

burntsushi 5y ago

The comparison doesn't really make much sense IMO. Searching with and without indexing is targeting two very different use cases. I wanted to try idutils and see if it suffered from pitfalls (like if the indexing scanner didn't grab a token) or how it handled regexes. But I couldn't get it compiled using these commands[1]. It failed with: gcc -DHAVE_CONFIG_H -I. -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -MT fseterr.o -MD -MP -MF .deps/fseterr.Tpo -c -o fseterr.o fseterr.c fseterr.c: In function 'fseterr': fseterr.c:74:3: error: #error "Please port gnulib fseterr.c to your platform! Look at the definitions of ferror and clearerr on your system, then report this to bug-gnulib." 74 | #error "Please port gnulib fseterr.c to your platform! Look at the definitions of ferror and clearerr on your system, then report this to bug-gnulib." | ^~~~~ make[3]: *** [Makefile:1590: fseterr.o] Error 1 So I can't even easily get idutils to try it, but suspicion is that it misses some key use cases. And from what I can tell, its index doesn't auto-update, so you now have to use your brain power to remember to update the index. (Or figure out how to automate it.) ripgrep is commonly used in source code repos, where you might be editing code or checking out different branches all the time. An indexing tool in that scenario without excellent automatic updates is a non-starter. [1] - https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=idutils https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=iduti...