12 ms·

Ripgrep is faster than grep, ag, git grep, ucg, pt, sift (2016)

• derodero24 7mo ago
  [flagged]
• pipe01 7mo ago
  (2016)
  • vintermann 7mo ago
    Maybe the first rust "killer app" in retrospect.
• keybored 7mo ago
  > The binary name for `ripgrep` is `rg`. I don’t understand when people typeset some name in verbatim, lowercase, but then have another name for the actual command. That’s confusing to me. Programmers are too enarmored with lower-case names. Why not Ripgrep? Then I can surmise that there might not be some program ripgrep(1) (there might be a shorter version), since using capital letters is not traditional for CLI programs. Look at Stacked Git: https://stacked-git.github.io/ https://stacked-git.github.io/ > Stacked Git, StGit for short, is an application for managing Git commits as a stack of patches. > ... The `stg` command line tool ... Now, I’ve been puzzled in the past when inputing `stgit` doesn’t work. But here they call it StGit for short and the actual command is typeset in verbatim (stg(1) would have also worked).
  • lpapez 7mo ago
    You can simply add a shell alias with whatever name you like and move on.
    • qsera 7mo ago
      True, but easier said than done, because one often need to work in more shells than their local machines..
      • pie_flavor 7mo ago
        This is a nonstandard tool. If you can't customize your machine, you already don't have it.
        • qsera 7mo ago
          But it could be one day..
      • worksonmine 7mo ago
        Do something like this to fall back to plain grep. You will somehow have to share these configurations across machines though. alias g=grep command -v rg 2>&1/dev/null && alias g=rg
    • BiteCode_dev 7mo ago
      You can't in most corporate env machines. You may be able to download ripgrep, and execute it (!), but god forbid you can create an alias in your shell in a persistant manner.
      • worksonmine 7mo ago
        > You can't in most corporate env machines. Really? "most" even? What CAN you do if you can't edit files in your own $HOME?
      • pentaphobe 7mo ago
        `[citation needed]`
      • OkayPhysicist 7mo ago
        huh? If you can download and execute files, you can alias it. Either in your .bashrc file, or by making a symlink.
        • BiteCode_dev 7mo ago
          I daily drive linux, but I hop from clients to clients and I have probably served about 200 different structures so far. Most corporate machines are Windows boxes with ps and cmd.exe heavily restricted, no admin, and anti malware software surveilling I/O like a hawk. You might get a git bash if you are lucky, but it's usually so slow it's completely unusable. In one client I once tried to sneak in Clink. Flagged instantly by security and reported to HR. It's easy to forget that life outside the HN bubble is still stuck there.
          • OkayPhysicist 7mo ago
            How can you possibly get development work done in an environment where you can even make a Microsoft.PowerShell_profile.ps1?
            • BiteCode_dev 7mo ago
    • keybored 7mo ago
      Sixty-six words about capitalizing things properly and you think this is something that learning about shell aliases can solve. Impressive.
  • orf 7mo ago
    It’s only 2 characters - if you use it all the time it becomes muscle memory.
  • Macha 7mo ago
    How would you capitalise it? RipGrep? RIPGrep? You’d need to pick a side and lose the pun. (And of course grep itself would need to be GReP if we took it all the way)
    • keybored 7mo ago
      I wrote Ripgrep.
      • pentaphobe 7mo ago
        And they wrote "... you'd need to pick a side and lose the pun.."
        • keybored 7mo ago
          And I am able to read four sentences.
          • pentaphobe 7mo ago
            Evidently reading isn't the same as comprehension
            • keybored 7mo ago
              Yeah, you repeatedly failing to comprehend that I made a choice already and don’t care about losing hacker pun points.
  • qudat 7mo ago
    Because we are constantly writing variables that are lowercase. Coming up with a name that is both short but immediately understandable is what we live for. Variables are our shrine, we stare at them everyday and are used to their beauty and simplicity.
  • vortegne 7mo ago
    Don't get me started on `nvim` to run neovim...
    • opan 7mo ago
      This was my first thought as well. I think I end up just calling it nvim sometimes even conversationally, the binary name is the most "real" thing to me.
• ianberdin 7mo ago
  It’s a pure delight to read this docs / pitch.
• dist-epoch 7mo ago
  (2024) gg: A fast, more lightweight ripgrep alternative for daily use cases https://reddit.com/r/rust/comments/1fvzfnb/gg_a_fast_more_lightweight_ripgrep_alternative/ https://reddit.com/r/rust/comments/1fvzfnb/gg_a_fast_more_li...
  • keybored 7mo ago
    > > IMO, as long as the time differences remain small, I'm totally okay with ripgrep being slower by default on smaller corpora if it means being a lot faster by default on bigger corpora. Also something-something about dependencies (a Rust staple): https://www.reddit.com/r/rust/comments/1fvzfnb/gg_a_fast_more_lightweight_ripgrep_alternative/lqbit1d/ https://www.reddit.com/r/rust/comments/1fvzfnb/gg_a_fast_mor...
    • masklinn 7mo ago
      Note that this is the author of ripgrep replying to a third party commenter asking whether rg isn’t already lightweight, and comparing the two under various possible definitions of “lightweight”.
      • keybored 7mo ago
        Yes.
• wewewedxfgdf 7mo ago
  I was using ripgrep once and it had a bug that led me downa terrifying rabbit hole - I can't recall what it was but it involved not being able to find text that absolutely should have been there. Eventually I was considering rebuilding the machine completely but for some reason after a very long time digging deep into the rabbit hole I tried plain old grep and there was the data exactly where it should have been. So it's such a vague story but it was a while back - I don't remember the specifics but I sure recall the panic.
  • RichardLake 7mo ago
    Was the file in a .gitignore by any chance? I've got my home folder in git to keep track of dot/config files and that always catches me out. Really dislike it defaulting to that ignoring files that are ignored by git.
    • worksonmine 7mo ago
      > Really dislike it defaulting to that ignoring files that are ignored by git. It's the reason I started using it. Got sick of grep returning results from node_modules etc.
      • dataflow 7mo ago
        You started using it because it had that capability I imagine, not because it is the default. You could easily just alias a command with the right flag if the capability was opt-in.
        • worksonmine 7mo ago
          No, because it was default. > You could easily just alias a command with the right flag if the capability was opt-in. I tried a search to make grep ignore .gitignore because `--exclude=...` got tedious and there was ripgrep to answer my prayers. Maintaining an alias would be more work than just `rg 'regex' .venv` (which is tab-completed after `.v`) the few times I'm looking for something in there. I like to keep my aliases clean and not have to use rg-all to turn off the setting I turned on. Like in your case, `alias rg='rg -u'`, now how do you turn it off?
• boyter 7mo ago
  Such a good read. I actually went back though it the other day to steal the searching for the least common byte idea out to speed up my search tool https://github.com/boyter/cs https://github.com/boyter/cs which when coupled with the simd upper lower search technique from fzf cut the wall clock runtime by a third. There was this post from cursor https://cursor.com/blog/fast-regex-search https://cursor.com/blog/fast-regex-search today about building an index for agents due to them hitting a limit on ripgrep, but I’m not sure what codebase they are hitting that warrants it. Especially since they would have to be at 100-200 GB to be getting to 15s of runtime. Unless it’s all matches that is.
  • tmarice 7mo ago
    Yeah, that Cursor blog post is a bit iffy since they just brush over the "ripgrep is slow on large monorepos", move on to techniques they used, and then completely ignore the fact that you have to build and maintain the index. On a mid-size codebase, I fzf- and rg-ed through the code almost instantly, while watching my coworker's computer slow down to a crawl when Pycharm started reindexing the project.
    • cess11 7mo ago
      I'm not into the low level minutiae but on large code bases I sometimes see a lag on the first rg:s I run and then it's fast, which I attribute to some OS level caching stuff. Perhaps they run their software on operating or file systems that can't do it, or on hardware with different constraints than the workstation flavoured laptops I use.
      • boyter 7mo ago
        The disk cache has a huge impact. However they claim it’s for multiple searches so it should be in it.
  • AbanoubRodolf 7mo ago
    [flagged]
• unxmaal 7mo ago
  I just got ripgrep ported to IRIX over the weekend. It’s fast even on a 300mhz Octane.
  • bartread 7mo ago
    Is IRIX experiencing a hobbyist revival or something? This is the second IRIX reference I’ve seen on here in the past two days, and there was a submission a day or two ago (c.f. a Voodoo video card?) as well. I haven’t personally encountered IRIX in the wild since a company I worked at in 2003. I suppose SGI has always had a cool factor but it’s unusual seeing it come up in a cluster of mentions like this.
    • unxmaal 7mo ago
      It ebbs and flows. SGUG tried hard to port newer packages for IRIX for several years but hit a wall with ABI mismatches leading to GOT corruption. This prevented a lot of larger packages from working or even building. I picked up the effort again after wondering if LLMs would help. I ran into the ABI problems pretty quickly. This time though, I had Claude use Ghidra to RE the IRIX runtime linker daemon, which gave the LLM enough to understand that the memory structures I’d been using in LLVM were all wrong. See https://github.com/unxmaal/mogrix/blob/main/rules/methods/irix-address-space.md https://github.com/unxmaal/mogrix/blob/main/rules/methods/ir... . After cracking that mystery I was able to quickly get “impossible” packages building, like WebKit, QT5, and even small bits of Go and Rust. I’m optimistic that we’ll see more useful applications built for this cool old OS.
      • speed_spread 7mo ago
        Ooh that's super interesting. I assume you shared the recipe with the irix community? I remember keeping Netscape up to date on my Indy was already a struggle in 2002.
      • bartread 7mo ago
        That is pretty neat. I guess this sort of unlocking and unblocking effort is exactly what’s needed for a revival. I’m sort of thinking of AmigaOS/Workbench as well although, perhaps because of what I would assume was always a much larger user base than SGI had, it maybe never went away like SGI and IRIX did. It is great seeing these old platforms get a new lease of life.
• chriswep 7mo ago
  It seems to me that `rg` is the number one most important part that enables LLMs to be smart agents in a codebase. Who would have thought that a code search tool would enable AGI?
• brtkwr 7mo ago
  Hasn’t someone rewritten ripgrep in rust by now? C’mon it’s 2026. Oh wait it was written in Rust (back in 2016).
  • masklinn 7mo ago
    The fun part is it is pretty easy to “rewrite” ripgrep in rust, because burntsushi wrote it as a ton of crates which you can reuse. So you can reuse this to build your own with blackjack and hookers.
    • mijoharas 7mo ago
      Gotta add a +1 for this. I wanted to do some ignore files etc for a project. I thought "well I kinda want to do what rg does". Had a little glance and it was already nicely extracted into a separate crate that was a dream to use. Thanks @BurntSushi!
    • SAI_Peregrinus 7mo ago
      A "ton of crates" is IMO the best way to write large Rust programs. Each crate in Rust is a compilation unit, the equivalent of one `.c` file in C. If they don't depend on one another, each crate can be compiled in parallel. It makes building the whole project faster, often significantly so. As with anything one can take it too far, but as long as each crate makes sense as an independent unit it's good.
      • loeg 7mo ago
        Isn't creating a bunch of crates pretty annoying, logistically (in terms of mandatory directory structure and metadata files per crate)? (Compared with C/C++ individual .c/.cpp files being compilation units.) And does parallel compilation of crates break LTO?
        • SAI_Peregrinus 7mo ago
          Not particularly annoying. You type `cargo new [options] <path>`, probably with the `--lib` option for a library crate, and it makes a new crate at <path>. Then you open the created lib.rs & cargo.toml in your editor & start writing code.
• craftkiller 7mo ago
  One of my favorite moments in HN history was watching the authors of the various search tools decide on a common ".ignore" file as opposed to each having their own: https://news.ycombinator.com/item?id=12568245 https://news.ycombinator.com/item?id=12568245
  • tmtvl 7mo ago
    I would argue that grep-like tools which read .gitignore violate the Principle of Least Astonishment (POLA). It would be fine if there were a --ignore flag to enable such functionality, but defaulting to it just feels wrong to me. Obviously smarter people than I disagree, but my dumdum head just feels that way.
    • justin66 7mo ago
      Agreed. It's a footgun.
    • rjzzleep 7mo ago
      Back in the day I would have agreed with you, but ever since there is js everywhere you end up with minified js that megabytes big and match everything. I still have muscle memory with `grep -r` and it almost always ends up with some js file, that I didn't know exists ruining the moment.
    • keybored 7mo ago
      It’s the kind of thing that maybe makes sense today. Less likely to make sense twenty years from now though. But that’s the kind of problem that only successful things have to worry about.
      • LeifCarrotson 7mo ago
        It probably wouldn't have made sense twenty years ago (or 60 years ago, when IBM engineers first wrote about the Principle of Least Astonishment [1] in 1966). But it does make sense today. I'd argue that modern computers do many astonishing and complicated and confusing things - for example, they synchronize with cloud storage through complex on-demand mechanisms that present a file as being on the users' computer, but only actually download it when it's opened by the user - and they attempt to do so as a transparent abstraction of a real file on the disk. But if ripgrep tried to traverse your corporate Google Drive or Dropbox or Onedrive, users might be "astonished" when that abstraction breaks down and a minor rg query takes an hour and 800 GB of bandwidth. It used to be that one polymath engineer could have a decent understanding of the whole pyramid of complexity, from semiconductors through spinlocks on to SQL servers. Now that goal is unachievable for most, and tools ought to be sophisticated enough to help the user with corner cases and gotchas that make their task more difficult than they expected it to be. [1]: https://en.wikipedia.org/wiki/Principle_of_least_astonishment#Origin https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...
• AdmiralAsshat 7mo ago
  Is it still?
• jedisct1 7mo ago
  ugrep is my daily driver. https://ugrep.com https://ugrep.com The TUI is great, and approximate matches are insanely useful.
• TacticalCoder 7mo ago
  And burntsushi is one of us: he's regularly here on HN. Big thanks to him. As soon as rg came out I was building it on Linux. Now it ships stocks with Debian (since Bookworm? Don't remember): thanks, thanks and more thanks.
  • aldanor 7mo ago
    Big thanks to him indeed (and for other projects in Rust space as well). // really hoping openai wouldn't now force him to work on some crappy codex stuff if he stays there / in astral.
• davikr 7mo ago
  qgrep is faster if you're fine with indexing. worth it
  • staticassertion 7mo ago
    Doesn't ripgrep support indexing too?
    • davikr 7mo ago
      not yet, but Cursor is working on it.
• drob518 7mo ago
  I’ve read this multiple times over the years and this post is still the most interesting and informative piece describing the problem of making a fast grep-like tool. I love that it doesn’t just describe how ripgrep works but also how all the other tools work and then compares the various techniques. It’s simultaneously a tutorial and an expert deep dive. Just a beautiful piece of writing. In a perfect world, all code would be similarly documented.
  • VorpalWay 7mo ago
    The same author also wrote the defacto standard regex library in Rust, and somewhat recently a new time and date library (jiff). The comparison between jiff, chrono, time and hifitime is just as good of a read in my opinion: https://github.com/BurntSushi/jiff/blob/HEAD/COMPARE.md https://github.com/BurntSushi/jiff/blob/HEAD/COMPARE.md (And they have also written interesting things on regex, non-regex string matching, etc.)
    • 1-more 7mo ago
      He also wrote the rust CSV parsing library and then the command line utility xsv that uses it. It's an incredible piece of software for breaking down massive CSV files where fields contain linebreaks and you thus cannot use sed to just get ranges of lines.
    • bashkiddie 7mo ago
      > wrote the defacto standard regex library in Rust What is the motivation that Rust invented its own RegEx flavor instead of sticking to PCRE or even RE2?
      • VorpalWay 7mo ago
        Not going with a dialect that supports back references ensures that you have can have linear complexity, which is important for some use cases. PCRE doesn't fot that. Not sure about RE2, I have never used that. Other than that it is standard regex syntax pretty much as far as I know? One library is pretty much like another. What differs is mostly availability of some less used extensions, and performance characteristics. If you accept untrusted regexes you want one with linear time complexity. On top of that the rust regex engine has really good performance when it comes to the constants too (not just the big O notation).
• travisdrake 7mo ago
  still a good read
• krick 7mo ago
  I don't remember why I didn't switch from ag, but I remember it was a conscious decision. I think it had something to do with configuration, rg using implicit '.ignore' file (a super-generic name instead of a proper tool-specific config) or even .gitignore, or something else very much unwarranted, that made it annoying to use. Cannot remember, really, only remember that I spent too much time trying to make it behave and decided it isn't worth it. Anyway, faster is nice, but somehow I don't ever feel that ag is too slow for anything. The switch from the previous one (what was it? ack?) felt like a drastic improvement, but ag vs. rg wasn't much difference to me in practice.
  • tom_alexander 7mo ago
    > I didn't switch from ag, [...] rg using implicit '.ignore' file (a super-generic name instead of a proper tool-specific config) The ".ignore" name was actually suggested by the author of ag (whereas the author of rg thought it was too generic): https://news.ycombinator.com/item?id=12568245 https://news.ycombinator.com/item?id=12568245
    • krick 7mo ago
      Totally agree with the author of rg here. Config names should be unambiguous. Anyway, must have been something else, then. As I've said, I cannot remember what was the specific problem, only that it wasn't quite compatible with the workflow I was used to, and now it'd take another full-in attempt to switch to figure out what was so annoying to me back then.
      • replooda 7mo ago
        If you ever do, please reply to this with why.
  • mijoharas 7mo ago
    I was just trying to remember why I switched _to_ rg. It's nice and everything, but I remember being happy with the tools before (I think i moved from grep to ack, then jumped due to perf to ag and for unremembered reasons to pt.) It took me a while, but I remembered I ran into an issue with pt incorrectly guessing the encoding of some files[0]. I can't remember whether rg suffered from the same issue or not, but I do know after switching to rg everything was plain sailing and I've been happy with it since. [0] https://github.com/monochromegane/the_platinum_searcher/issues/174 https://github.com/monochromegane/the_platinum_searcher/issu...
• cbm-vic-20 7mo ago
  fd:find::rg:grep Someone please make an awesome new sed and awk.
  • scns 7mo ago
    sd exists, dunno but awk. https://github.com/chmln/sd https://github.com/chmln/sd
  • deleted 7mo ago
    [deleted]
  • johnisgood 7mo ago
    How is GNU / BSD sed and awk not awesome?
    • MrDrMcCoy 7mo ago
      Limited regex capabilities. A fast tool that does what sed and awk do with PCRE2 would be amazing.
      • johnisgood 7mo ago
        Well, I would like to tackle that but unfortunately I do not have enough time to do things for free. :( Is there any demand for it anyway?
        • MrDrMcCoy 7mo ago
          I think there would be, but I can only raise my own hand :-) A tool called sd exists that's close enough for sed, but I haven't seen anything similar for awk.
          • johnisgood 7mo ago
            I took a minute to think about it. It would be much more work to add it to awk. :( And replacing every regex evaluation could slow scripts significantly, although this could be a good challenge! :D Are you using "sd" or is there anything wrong with it as a replacement of sed?
• npn 7mo ago
  Faster is not always the best thing. I still remember when vs code changed to ripgrep I had to change my habit using it, before then I can just open vs code to any folder and do something with it, even if the folder contains millions of small text files. It worked fine before, but then rg was picked, and it happily used all of my cpu cores scanning files, made me unable to do anything for awhile. To be honest I hate all the new rust replacement tools, they introduce new behavior just for the sake of it, it's annoying.
• dinkumthinkum 7mo ago
  There is also upgrep, which is quite a good project. https://github.com/Genivia/ugrep https://github.com/Genivia/ugrep
  • vintagedave 7mo ago
    I recall that it was also very close in performance. When it was posted here, it beat ripgrep! https://news.ycombinator.com/item?id=38819262 https://news.ycombinator.com/item?id=38819262
  • infocollector 7mo ago
    This is what my default grep is. You probably want to update your comment to reflect the correct name. (ugrep)
• dmix 7mo ago
  When Claude Code uses `grep` it's actually using `rg` underneath
  • stared 7mo ago
    Oh, interesting! I had a user prompt that suggest using rg not grep, but was annoyed that it uses rg.
  • tmp10423288442 7mo ago
    Codex does as well, although I think it actually shows it running `rg`.
  • arthurjean 7mo ago
    It even ships a bundled rg binary via @vscode/ripgrep — you can switch to your system rg with USE_BUILTIN_RIPGREP=0 for better perf. One gotcha worth knowing: in non-git repos, .gitignore rules are silently ignored because rg doesn't pass --no-require-git by default.
• wolandark 7mo ago
  and incompatible with grep syntax, which makes it useless to most system admins
  • xpe 7mo ago
    > and incompatible with grep syntax, which makes it useless to most system admins I wonder how much the above reflects a dated and/or stereotyped view? Who here works with "sysadmins"? I mean... devops-all-the-places now, right? :P Share your experiences?: I'm curious. If I were a sysadmin, I'd have some kind of "sanity check" script if I had to manage a fleet of disparate systems. I'd use it automatically when I logon to a system. Checking things like: Linux vs BSD, what tools are installed, load, any weirdnesses, etc. Heck, maybe even create aliases that abstract over all of it, as much as possible. Maybe copy over a helix binary for editing too, if that was kosher.
  • tmp10423288442 7mo ago
    Any sysadmin worth their salt turns on extended regular expressions (with `-E` or `egrep`), which Ripgrep's regex syntax is a superset of, more or less.
• devnotes77 7mo ago
  [dead]
• raincole 7mo ago
  When I first heard about ripgrep my reaction was laughing. grep had been too established. No way something that isn't 100% compatible with grep could get any traction. And I was dead wrong. Overnight everyone uses rg (me included).
• rsmtjohn 7mo ago
  [flagged]
• groundzeros2015 7mo ago
  That’s because it doesn’t do the same work. It’s not an equivalent tool to grep.
• ventana 7mo ago
  One thing I learned over the years is that the closer my setup is to the default one, the better. I tried switching to the latest and greatest replacements, such as ack or ripgrep for grep, or httpie for curl, just to always return to the default options. Often, the return was caused by a frustration of not having the new tools installed on the random server I sshed to. It's probably just me being unable to persevere in keeping my environment customized, and I'm happy to see these alternative tools evolve and work for other people.
  • ozim 7mo ago
    Story of my life basically. It is just too much effort to keep customization preserved.
    • zeppelin101 7mo ago
      I would say some of the 'newer' tools like rg and jq are just about essential.
  • wredcoll 7mo ago
    This sort of thing is a constant tension and it's highly likely to be a different optimum for every individual, but it's also important not to ignore genuine improvements for the sake of comfort/familiarity. I suspect, in general, age has a fair amount to do with it (I certainly notice it in myself) but either way I think it's worth evaluating new things every so often. Something like rg in specific can be really tricky to evaluate because it does basically the same thing as the builtin grep, but sometimes just being faster crosses a threshold where you can use it in ways you couldn't previously. E.g. some kind of find as you type system, if it took 1s per letter it would be genuinely unusuable but 50ms might take it over the edge so now it's an option. Stuff like that.
• tgtweak 7mo ago
  codex is basically a ripgrep wrapper at this point :)
• evilturnip 7mo ago
  nowgrep is supposedly even faster than ripgrep: https://x.com/CharlieMQV/status/1972647630653227054 https://x.com/CharlieMQV/status/1972647630653227054
  • temphaaa 7mo ago
    *on windows as the tweet says
  • GorbachevyChase 7mo ago
    They discovered the nowgorithm.
  • MrDrMcCoy 7mo ago
    Closed-source, no-release. Why bother linking it?
• sy0115 7mo ago
  [dead]
• nikisweeting 7mo ago
  Ripgrep is used as the defautl search backend for ArchiveBox, such a good tool. I was on ag (the-silver-searcher) for years before I switched, but haven't gone back since. There's also RGA (ripgrep-all) which searches binary files like PDFs, ebooks, doc files: https://github.com/phiresky/ripgrep-all https://github.com/phiresky/ripgrep-all
• Royalaid 7mo ago
  I don't know if this is coincidence or not but Cursor just made a post breaking down why they moved to their own solution in place or Ripgrep and it makes a lot of sense from a cursory (haha) read. https://cursor.com/blog/fast-regex-search https://cursor.com/blog/fast-regex-search
• Self-Perfection 7mo ago
  HWisnu wrote cgrep that he asserts is even faster, especially on loaded system. He posted interesting benchmarks https://hwisnu.bearblog.dev/building-cgrep-using-safe_ch-custom-header-new/ https://hwisnu.bearblog.dev/building-cgrep-using-safe_ch-cus... It seems this was possible because ripgrep is inefficient in CPU usage when runs multithreaded and uses about 2x times more CPU time in comparison to GNU grep. https://hwisnu.bearblog.dev/levelized-cost-of-resources-in-benchmarks/ https://hwisnu.bearblog.dev/levelized-cost-of-resources-in-b...
• pgporada 7mo ago
  Last week I experienced a data truncation issue where I ran an rg -zF fixed string search piped into another rg -F. The dataset was roughly 10 million lines. Doing a single rg -z with a regex glob in the middle didn't encounter that issue.
• p2detar 7mo ago
  I did a small, 3-runs test on M3 and the results were shockingly impressive. With 240 log files in various subfolders. grep -q -r "22:02" --include=".log" 4.15s user 0.09s system 99% cpu 4.269 total grep -q -r "22:02" --include=".log" 4.18s user 0.09s system 99% cpu 4.265 total grep -q -r "22:02" --include="*.log" 4.31s user 0.09s system 99% cpu 4.401 total rg -q "22:02" -t log 0.01s user 0.01s system 83% cpu 0.018 total rg -q "22:02" -t log 0.01s user 0.01s system 93% cpu 0.017 total rg -q "22:02" -t log 0.01s user 0.01s system 95% cpu 0.018 total I really did not expect it to be that fast.
• Innoraai 7mo ago
  [dead]