Windows search is slow and painful for developers. Even tools like Everything or PowerShell Get-ChildItem can crawl on huge directories. I wanted a CLI tool that feels instant—so I built rq, an open-source file search utility in modern C17 that leverages parallel directory traversal.
rq is typically 3–7x faster than common alternatives, supports filters (size, date, type, regex, glob), and streams results as text or JSON. It’s designed for scripting and developer workflows.
Why not just use existing tools?
• Windows Explorer: slow, not scriptable
• PowerShell: Get-ChildItem is painfully slow
• Everything: fast, but GUI-first
• ripgrep: amazing, but focused on text content search
rq focuses on metadata-based search for files and directories on Windows.
Core challenges:
1. Handling Windows quirks like MAX_PATH and Unicode (rq uses \?\ paths and UTF-8 internally)
2. Efficient parallel traversal without burning CPUs
3. Adding powerful filters without making everything slow
Design highlights:
• Custom thread pool built on Windows Thread Pool API
• Directory traversal is fully parallel: each worker processes directories and queues subdirectories
• CLI filters: size, extension, date, regex, glob, file type
Lessons learned:
• C17 is still great for high-performance tools
• Windows APIs are powerful but painful for paths and Unicode
• Thread pools beat raw threads for scalability
• Avoid syscalls in the hot path for speed
This tool looks great. Congrats for the making of this tool. I would like to know if there is any internal file that could be used to create a benchmark from it in order to compare how fast it gets results in comparison with Void Everything, which is the most common app if a Windows user would like to improve file search.
seeyebe · 4h ago
Thanks! Great question. Everything is an excellent tool, but it works differently—it uses a pre-built index, while rq scans the file system in real time.
rq is typically 3–7x faster than common alternatives, supports filters (size, date, type, regex, glob), and streams results as text or JSON. It’s designed for scripting and developer workflows.
Why not just use existing tools? • Windows Explorer: slow, not scriptable • PowerShell: Get-ChildItem is painfully slow • Everything: fast, but GUI-first • ripgrep: amazing, but focused on text content search
rq focuses on metadata-based search for files and directories on Windows.
Core challenges: 1. Handling Windows quirks like MAX_PATH and Unicode (rq uses \?\ paths and UTF-8 internally) 2. Efficient parallel traversal without burning CPUs 3. Adding powerful filters without making everything slow
Design highlights: • Custom thread pool built on Windows Thread Pool API • Directory traversal is fully parallel: each worker processes directories and queues subdirectories • CLI filters: size, extension, date, regex, glob, file type
Example usage: rq D:\ “*.png” –glob –min 1M –after 2024-01-01 –threads 8
Performance benchmark (1.2M files on NVMe SSD, Windows 11, Ryzen 7): • rq (8 threads): 3.2s • Everything CLI: 6.8s • PowerShell Get-ChildItem: ~40s
Lessons learned: • C17 is still great for high-performance tools • Windows APIs are powerful but painful for paths and Unicode • Thread pools beat raw threads for scalability • Avoid syscalls in the hot path for speed
Source: https://github.com/seeyebe/rq
To benchmark, you can use hyperfine like this:
hyperfine 'rq C:\ ".png" --glob' 'es.exe .png' 'fd --type f png'
This compares rq, Everything CLI (es.exe), and fd.