51–60 of 198 posts
What are the reasons for grep not being replaced/improved? This topic seems a bit old by now.
It's fast indeed. And I can't help keeping promoting the combination with fzf :) For those who want to try it out, this is a Powershell function but the same principle applies in any shell. Does ripgrep then puts fuzzy searching in the resulting files+text on top while showing context in bat: function frg { $result = rg --ignore-case --color=always --line-number --no-heading @Args | fzf --ansi ` --color 'hl:-1:underl…
Infact I would recommend a step further to integrate rip-grep-all (rga) with fzf that can do a fuzzy search not just on text files but on all types of files including pdfs, zip files. More details here [1] [1] https://github.com/phiresky/ripgrep-all/wiki/fzf-Integration
I can't think of a single time I've used grep where I thought "I wish this was faster".
I never worked out how that could be happening.
I can't think of a single time I've used grep where I thought "I wish this was faster".
I switched from from ripgrep to ugrep and never looked back. It's just as fast, but also comes with fuzzy matching (which is super useful), a TUI (useful for code reviews), and can also search in PDFs, archives, etc. The optional Google search syntax also very convenient. https://ugrep.com
Earlier quoted context omitted.
Not exactly but yes, it ultimately uses the `memchr` crate [1] which provides SIMD-optimized character and string search routines. But it uses `_mm256_cmpeq_epi8` instead of `_mm256_sad_epu8`. [1] https://docs.rs/memchr/latest/memchr/
And also the SIMD in aho-corasick, which is used whenever a small number of literals are searched for. For example, `foo|bar` or `(?i)foo`. https://github.com/BurntSushi/aho-corasick/blob/f227162f7c56... But no `_mm256_sad_epu8`. What an oddly specific question..?
It computes `sum(|x[i] - y[i]|)` for consecutive `i` at different offsets, so it should be zero at substring matches.
For context: https://epubs.siam.org/doi/pdf/10.1137/1.9781611972931.10
I was slightly mistaken, the instruction of interest is _mm256_mpsadbw_epu8
I can't think of a single time I've used grep where I thought "I wish this was faster".
A few years ago I worked on a Solaris box that would lock the whole machine up whenever I grepped through the log files. Like it wouldn't just be slow, the web server that was running on it would literally stop serving requests while it was grepping. I never worked out how that could be happening.
Another possibility is that your grep search was hogging up your system's memory. That might make it swap. On my systems which do not have swap enabled but do have overcommit enabled, I experience out-of-memory conditions as my system essentially freezing for some period of time until Linux's OOM-killer kicks in and kills the offending process.
I would say the first is more likely than the second. In order for grep to hog up memory, you need to be searching some pretty specific kinds of files. A simple log file probably won't do it. But... a big binary file? Sure:
grep -a burntsushi /proc/self/pagemap
(There are other reasons for a system to lock up, but the above two are the ones that are pretty common for me. Well, in the past anyway. Now my machines have oodles of RAM and lots of I/O bandwidth.)
It's fast indeed. And I can't help keeping promoting the combination with fzf :) For those who want to try it out, this is a Powershell function but the same principle applies in any shell. Does ripgrep then puts fuzzy searching in the resulting files+text on top while showing context in bat: function frg { $result = rg --ignore-case --color=always --line-number --no-heading @Args | fzf --ansi ` --color 'hl:-1:underl…
Vim is almost broken for me without fzf+rg. Feels like I’m manually grinding coffee instead of using electricity.
I switched from from ripgrep to ugrep and never looked back. It's just as fast, but also comes with fuzzy matching (which is super useful), a TUI (useful for code reviews), and can also search in PDFs, archives, etc. The optional Google search syntax also very convenient. https://ugrep.com
So I was casually searching for "ugrep vs ripgrep" articles, when I stumbled upon a couple reddit posts where apparently the authors of ugrep and ripgrep seemed to have a multi-year feud on reddit, eg. https://www.reddit.com/r/programming/comments/120wqvr/ripgre... So weird. I mean, it's just about some open source tool, right? :-/
There are feuds about open source tools all the time. Text editors, Linux distros, shells, programming languages, desktop environments, etc... And ugrep vs ripgrep may be a poster child for C++ vs Rust.
It is not all bad, it drives progress, and it usually stays at a technical level, I've yet to see people killing each others for their choice of command line search tool.
I switched from from ripgrep to ugrep and never looked back. It's just as fast, but also comes with fuzzy matching (which is super useful), a TUI (useful for code reviews), and can also search in PDFs, archives, etc. The optional Google search syntax also very convenient. https://ugrep.com
So I was casually searching for "ugrep vs ripgrep" articles, when I stumbled upon a couple reddit posts where apparently the authors of ugrep and ripgrep seemed to have a multi-year feud on reddit, eg. https://www.reddit.com/r/programming/comments/120wqvr/ripgre... So weird. I mean, it's just about some open source tool, right? :-/