Numbers, with their terms attached
Performance claims are easy to write; the hard part is saying where they came from. Every figure below carries its measurement conditions — including what we never measured.
The environment first: these are historical internal runs on an Intel MacBook Pro 2018 (i9-8950HK, 12 logical cores, 32 GiB), from different versions and macOS releases. Version, warm-ups, sample counts and cache conditions differ by source; the terms below state what is recorded and what was not controlled. These figures do not represent Apple Silicon performance; we have not re-run them on Apple Silicon or fully repeated this set on 1.8. Internal query timings do not measure the full response from keystroke to rendered results.
Internal search and filtering timings
| Item | Value | Terms |
|---|---|---|
| Internal query-latency threshold | 1M entries p95 ≤ 5 ms 5M entries p95 ≤ 20 ms | A line the product holds itself to — not a single best run |
| Path-scoped queries | 1M entries p95 13.5–13.9 ms 5M entries p95 64.6–66.8 ms | 1.4.1, 2026-07-28, Release, fixed seed: in:4095, 2 warm-ups and 10 measured queries per round, 3 rounds; identical result fingerprints. System load and OS page cache were not controlled. |
| Repeatedly narrowing the same scope | p95 330 ms → 81 msSame machine and data, −75.4% | 2026-08-20, Release, macOS 15.7.9; fixed 5M dataset, in:4095 report, B→C→C→B (2 runs per binary), means of the per-run p95 values; fingerprints match. Warm-up and per-run query counts were not stated for this matrix. |
| Recompute after changing a display filter | Depends on scope and query | Timing depends on the indexed scope and active filters; no fixed cross-machine timing is published for this operation. |
From a file changing to being searchable
Indexing, memory and index size
| Item | Value | Terms |
|---|---|---|
| Synthetic index build | 5M entries in 3.5 sMedian of 3 rounds, 2026-07-29 | This excludes a real disk’s first scan — fixed synthetic dataset, Release; system load and OS page cache were not controlled. The historical 39.5 s figure came from an older version, not this same-session comparison. |
| First full scan of a real disk | Depends on drive and file countA whole disk can reach the tens-of-minutes range | We do not publish a fixed cross-machine number, because that would be invented. Everyday folders are searchable while it runs |
| Idle CPU | Free ≈0.08%; Pro ≈0.42–0.54% single-core equivalent | 1.6.1 (169), Free 133k entries: 91 s, ≈0.077%; 1.6.5 (172), full disk after build: 60 s, ≈0.42%, then an independent 48 s window, ≈0.54%. Separate scopes and observation windows. |
| Memory just after launch, before an index is built | ≈23.7 MB physicalPeak 24.0 MB | 1.6.4 (144), CleanState development build; independent launch, sampled after 20 s with vmmap -summary, before any index was built. This is physical footprint, not RSS; wider scope costs more. |
| Steady-state memory threshold | ≤ 200 MB at 1M entries | A line the product holds itself to; transient build peaks adapt to available system memory and are released immediately |
| Index size | ≤ 150 MB at 1M entries≈23 MB for the free tier's 133k entries | The index holds only names, paths, sizes and timestamps — no file contents |
Stating the gaps too
- Nothing here has been re-run on Apple Silicon. Every figure above comes from the same Intel machine.
- There is no cross-machine "your first full scan will take N minutes" number — it depends on your drive type, file count and system state.
- "5 million" describes an index scale exercised repeatedly in development benchmarking. It is not a prediction about your disk.
- We avoid absolute claims like "the fastest": we publish only what we measured ourselves, and make no comparative speed claims against other tools.
The fastest way to verify is to install it
The free tier is free forever. The status bar shows the live result count and how long the query took — the number on your own Mac is more convincing than ours.