fff, codedb, ripgrep, grep, fd, and find tested head-to-head on the Cloudflare docs repo. All pre-indexed tools use warm MCP servers. All filesystem tools use warm OS page cache.
Both tools index once and serve queries from memory. codedb uses trigram + inverted word indexes (Zig). fff uses mmap + SIMD grep (Rust). Median latency over 20 runs via MCP JSON-RPC.
| Query | codedb | fff | rg | grep | codedb vs rg | fff vs rg |
|---|---|---|---|---|---|---|
function | 0.090ms | 1.413ms | 179.03ms | 14,991ms | 1,989x | 127x |
addEventListener | 0.065ms | 0.519ms | 172.78ms | 14,224ms | 2,658x | 333x |
Durable Objects | 0.129ms | 0.371ms | 173.25ms | 13,825ms | 1,343x | 467x |
handleRequest | 0.090ms | 0.399ms | 172.93ms | 14,342ms | 1,921x | 433x |
*.ts export | 0.148ms | 0.377ms | 19.88ms | 50.71ms | 134x | 53x |
Log-scaled bars showing the full range from sub-millisecond indexed search to 15-second GNU grep. Each bar group shows codedb, fff, ripgrep, and GNU grep.
fff uses fuzzy matching on its in-memory index. fd and find traverse the filesystem. codedb has codedb_tree but no equivalent fuzzy file finder.
| Query | fff | fd | find | fff vs fd |
|---|---|---|---|---|
wrangler.toml | 1.31ms | 20.55ms | 71.97ms | 16x |
config | 1.05ms | 79.71ms | 70.79ms | 76x |
src/content/workers | 1.17ms | 4.46ms | 4.02ms | 4x |
*.mdx | 0.49ms | 22.08ms | 79.64ms | 45x |
wranglerconf (typo) | 1.21ms | 20.05ms | 64.97ms | 17x |
ts | 0.80ms | 21.30ms | 59.48ms | 27x |
fff found 587 results for the typo "wranglerconf" vs fd's 2 and find's 1.
What AI agents actually see: JSON-RPC over stdio, including serialization overhead. fff (left) and codedb-only features (right).
These two tools solve the same problem — fast code search for AI agents — with radically different engineering choices. Understanding the architecture explains every number above.
| Tool | Cold Start | Warm Start | What Happens |
|---|---|---|---|
| fff | 72–92ms | 72–92ms | Walk git index, mmap every file into virtual memory |
| codedb | 7,200ms | 585ms | Parse every file, build trigram + word index + outlines + dep graph; or load snapshot |
| ripgrep | 0ms | 0ms | No index — walks filesystem and reads files on every query |
fff's startup is 78x faster than codedb cold start, 6x faster than codedb warm start. Both are one-time costs amortized across the session. ripgrep pays its cost on every query instead.
mmap() on each file, asking the OS kernel to map file bytes directly into the process's virtual address space. This is not "reading" the files — no data is copied into userspace yet. The kernel just sets up page table entries.
addEventListener, fff scans through the mmap'd pages using SIMD vector instructions (ARM NEON / x86 SSE/AVX). It processes 16–32 bytes per CPU cycle, comparing against the search pattern in parallel. Pages that were already touched are in the kernel page cache (RAM); untouched pages trigger a page fault that loads them from disk transparently.
multi_grep builds a finite state automaton from all patterns at query time and matches them in a single pass. This is faster than running N separate greps because the automaton only traverses each byte once regardless of pattern count.
codedb.snapshot file for 585ms warm restarts.
addEventListener via codedb_word is a single hash table lookup — O(1) regardless of repo size. The index already knows every file and line where that exact token appears. No file content is read at query time. This is why it's 4–16x faster than fff's SIMD scan: it's not scanning anything at all.
codedb_search (substring/regex), codedb extracts trigrams from the query (e.g., "add", "ddE", "dEv" for "addEventListener"), intersects the file sets for each trigram to get candidates, then does a brute-force scan only on those candidate files. This avoids scanning 99% of files, achieving 5.5x speedup over full scan.
codedb_outline tool returns these symbols for a file — 4–15x fewer tokens than reading the raw file. codedb_symbol finds where a symbol is defined across the codebase. fff has no structural awareness.
codedb_deps answers "which files import this file?" — useful for impact analysis before refactoring. This is computed during indexing and has no equivalent in any search tool.
| Capability | fff | codedb | ripgrep |
|---|---|---|---|
| Content search (grep) | SIMD scan | trigram + brute | regex engine |
| Exact word lookup | — | O(1) hash | — |
| Fuzzy / typo-tolerant search | Smith-Waterman | — | — |
| Regex support | auto-detect | flag | native |
| Multi-pattern OR | Aho-Corasick | — | — |
| File finding (fuzzy) | frecency-ranked | tree only | — |
| Frecency ranking | LMDB-backed | — | — |
| Auto-retry on 0 results | 3 fallbacks | — | — |
| Definition auto-expand | context lines | outlines | — |
| Symbol / structural search | — | parsed AST | — |
| Dependency graph | — | reverse deps | — |
| Atomic file edits | — | versioned | — |
| Git-dirty file boosting | in ranking | — | — |
| Persistent file watching | fsevents | 2s polling | — |
| Language | Rust | Zig | Rust |