fd vs find: I Benchmarked Both on a 20K-File Tree

Ever wondered whether fd is actually faster than find, or just more comfortable to type? I set up a synthetic 20,000-file tree on a Linux server and timed both tools on three search tasks. Here are the real numbers.

Official: fd on GitHub · GNU Findutils

What You Will Need

1. A Linux server (I used Ubuntu 26.04 on 2 vCPUs)
2. python3 with matplotlib for the chart
3. fd-find (install: apt install fd-find)
4. time — or use Python’s perf_counter() like I did

How I Tested

I generated 100 directories, each containing 200 files with random extensions (.log, .txt, .conf, .py, .json, etc.) and random content. This gave exactly 20,000 files — all synthetic, all RFC 5737-safe, no personal data touched. I warmed the page cache with one find pass before timing to isolate tool performance from disk I/O.

fd matches against the file basename by default, while find always matches against the full path. For the regex test I ran fd --full-path to make it a fair comparison on the same field.

The Benchmark Script

#!/usr/bin/env python3
import subprocess, time, random, string, os, shutil
from pathlib import Path

def seed_tree(base, dirs=100, files=200):
    if base.exists(): shutil.rmtree(base)
    base.mkdir(parents=True)
    for i in range(dirs):
        d = base / f"dir{i:04d}"
        d.mkdir()
        for j in range(files):
            ext = random.choice(['.log','.txt','.conf','.py'])
            content = os.urandom(random.randint(50,500))
            (d / random_filename(ext)).write_bytes(content)
    return dirs * files

# ... run and time each tool ...
print("See full script at /root/bench-fd-find.py")

#!/usr/bin/env python3
import subprocess, time, random, string, os, shutil
from pathlib import Path

def seed_tree(base, dirs=100, files=200):
    if base.exists(): shutil.rmtree(base)
    base.mkdir(parents=True)
    for i in range(dirs):
        d = base / f"dir{i:04d}"
        d.mkdir()
        for j in range(files):
            ext = random.choice(['.log','.txt','.conf','.py'])
            content = os.urandom(random.randint(50,500))
            (d / random_filename(ext)).write_bytes(content)
    return dirs * files

# ... run and time each tool ...
print("See full script at /root/bench-fd-find.py")

Results

Each task ran three times; the table below shows the fastest run.

Observations

fd won every test. The gap was modest on simple glob searches (1.4-1.6x) but widened to 3.4x on regex, where fd’s Rust regex engine outpaces find -regextype posix-extended. Both tools returned identical file counts for all three tasks, confirming the comparison was fair.

One gotcha: fd v10.3.0 matches against the basename by default, not the full path. If you want to match directory names or full paths, pass --full-path. I hit this during setup — my first test found 0 files for the regex that worked instantly with find.

Feature Comparison

Which One Should You Use?

If you work in a terminal all day, switch to fd for interactive searches. The speed difference matters less than the ergonomics: sensible defaults (hides .dotfiles, colors output, smart case) make it the better daily driver. Install it, alias fd to fdfind if your distro names it that way, and don’t look back.

But keep find in your scripts. It ships on every Linux system, its POSIX syntax is stable across decades and distributions, and nothing beats it for portability. Write your cron jobs with find; use fd when you are the one reading the output.

For more CLI comparison benchmarks, check out my post on ripgrep vs grep for log searching, and jq vs Python for JSON wrangling speed. If you are hunting down logs that logrotate missed, this Python log scanner might help too.