Blog
Bài dài đằng sau video.Không lòng vòng, dự án thật.
Build note, bài học code, và review chân thật từ dự án đằng sau mỗi video.
Blog
Build note, bài học code, và review chân thật từ dự án đằng sau mỗi video.
FFF is a file search toolkit built in Rust that keeps a warm index in memory, claiming sub-10-millisecond query times on repositories where each ripgrep invocation takes several seconds. It is designed for the specific workload of AI coding agents and editors that search the sam…
FFF is a file search toolkit built in Rust that keeps a warm index in memory, claiming sub-10-millisecond query times on repositories where each ripgrep invocation takes several seconds. It is designed for the specific workload of AI coding agents and editors that search the same repository hundreds of times in a single session.
FFF, short for "Fast File Finder," is a file and content search toolkit designed for both humans and AI agents. Unlike traditional search tools that spawn a new process and scan the filesystem for each query, FFF maintains a long-lived process that holds an index and cache in memory. A background watcher updates the index as files change, so subsequent queries do not need to rescan the entire repository.
The toolkit exposes path search, content search (grep), fuzzy matching, smart-case sensitivity, frecency ranking, and Git-aware annotations. It is available through multiple integrations: Neovim, an MCP server for AI agents, and Rust, C, and Node/Bun SDKs. The MCP server is particularly relevant because it brings FFF's search capabilities into coding agents like Claude Code, Cursor, Codex, Cline, and OpenCode.
fffind and ffgrep to coding agents, making the speed advantage available inside the agent workflows where it matters most.FFF runs as a persistent process that indexes the repository on startup and maintains the index in memory. A background file watcher detects changes and updates the index incrementally, so the index stays current without full rescans. When a query arrives, FFF looks up the in-memory index and returns results directly, avoiding the filesystem traversal that makes cold-start tools slow on large repositories.
According to the project's README, on a Chromium checkout with approximately 500,000 files, FFF queries after warm-up can complete in under 10 milliseconds, while each ripgrep process spawn takes 3 to 9 seconds. The same Rust core powers all integrations, so the Neovim plugin, MCP server, and SDKs all share the same performance characteristics.
The performance numbers are claims published by the FFF project itself, not independently verified benchmarks. The sub-10-millisecond figure applies to warm queries on a long-lived process: it does not mean FFF is faster than ripgrep for a single one-off search. The speed advantage comes at the cost of RAM. The README estimates approximately 26 MB of memory for a 14,000-file repository and several hundred MB for a 500,000-file repository. There is also a warm-up period: the initial index build takes time before queries become fast. FFF is not a replacement for ripgrep in every scenario: it is most valuable when you have a long-running process that searches the same repository repeatedly. If your workflow involves one-off searches across different directories, the overhead of maintaining a warm index may not pay off. Finally, as with any install script, you should review the curl-pipe-bash installation command before running it.
FFF is for developers and teams whose workflow involves repeated searching within the same large repository: AI coding agents, IDE extensions, Neovim users, and pre-commit tooling. If your agent spends significant time waiting for file search results, FFF's warm-index approach can meaningfully reduce that overhead. If you only search occasionally or work across many small repositories, the memory and warm-up costs may not be justified.
The honest summary: FFF trades RAM and warm-up time for repeated-query speed. Measure it on your actual workflow before committing.