Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The future of code search is not regex – 100x faster than ripgrep

fff.dmtrkovalenko.dev

Post reply on HN
Print view View original

31–40 of 46 posts

Re: The future of code search is not regex – 100x faster than ripgrep

#34

Post by austinjp »

To save people the digging, here's the git repo:

https://github.com/dmtrKovalenko/fff.nvim

"FFF stands for freakin fast fuzzy file finder (pick 3) and it is an opinionated fuzzy file picker for your AI agent and Neovim. Just for file search, but we do the file search really fff well.

FFF is a tool for grepping, fuzzy file matching, globbing, and multigrepping with a strong focus on performance and useful search results. For humans - provides an unbelievable typo-resistant experience, for AI agents - implements the fastest file search with additional free memory suggesting the best search results based on various factors like frecency, git status, file size, definition matches, and more."

Re: The future of code search is not regex – 100x faster than ripgrep

#36

Post by adrian17 »

austinjp wrote: post #34

To save people the digging, here's the git repo: https://github.com/dmtrKovalenko/fff.nvim "FFF stands for freakin fast fuzzy file finder (pick 3) and it is an opinionated fuzzy file picker for your AI agent and Neovim. Just for file search, but we do the file search really fff well. FFF is a tool for grepping, fuzzy file matching, globbing, and multigrepping with a strong focus on performance and useful search resul…

So the repo builds:

- C library

- neovim plugin

- MCP server

But not a plain binary, which is the main way ripgrep is directly used (...at least by humans), and compared with.

Re: The future of code search is not regex – 100x faster than ripgrep

#37

Post by neogoose »

self_awareness wrote: post #22

I've entered "bazel" and got `shellPrefix.ts` which doesn't relate to bazel in any way. If that's the future then I'll stay in the past with ripgrep.

if you would search in the chromium repo you would see the correct match https://fff.dmtrkovalenko.dev/?repo=2&q=bazel

Re: The future of code search is not regex – 100x faster than ripgrep

#38

Post by neogoose »

Yokohiii wrote: post #25
genewitch wrote: post #8

considering that ripgrep has marginal overhead over just reading the files to /dev/null, how exactly does this achieve 100x speedup? I have a lot of use for something that can search ~1GB of text "instantly", but so far nothing beats rg/ag after the data has been moved into RAM.

The crate says it uses SIMD, but the crate also says that content search is 20-50 times faster. Maybe the guy unsure how fast it is or how much speedup he should claim to get recognition.

it very much depends on the platform and the operating system

for example ripgrep doesn't do any memory mapping on macos which makes it 2-3x faster just becuase of that

Re: The future of code search is not regex – 100x faster than ripgrep

#39

Post by neogoose »

narinciye wrote: post #31
wiseowise wrote: post #17

The future is lack of scrolling on mobile, and scanning getting stuck, apparently.

You don't miss much, don't worry, it also looks horrible on desktop.

it looks absolutely gorgeous btw but the idea is that you can try the search speed not actually use lmao

Re: The future of code search is not regex – 100x faster than ripgrep

#40

Post by neogoose »

adrian17 wrote: post #36
austinjp wrote: post #34

To save people the digging, here's the git repo: https://github.com/dmtrKovalenko/fff.nvim "FFF stands for freakin fast fuzzy file finder (pick 3) and it is an opinionated fuzzy file picker for your AI agent and Neovim. Just for file search, but we do the file search really fff well. FFF is a tool for grepping, fuzzy file matching, globbing, and multigrepping with a strong focus on performance and useful search resul…

So the repo builds: - C library - neovim plugin - MCP server But not a plain binary, which is the main way ripgrep is directly used (...at least by humans), and compared with.

because it is meant to be used by the long running sdk not one shot search (this is where all the optimizations are coming from)
Post reply on HN