Readit NewsDo those questions matter to you? They don't matter to me at all, so I'm curious to hear about why they matter to you. What do they matter to you for?
Knowing which code changes frequently or infrequently doesn't actually tell you anything about what code should change, because recency and frequency are not valid proxies for importance.
I installed this via mise. `mise use ubi:seeyebe/gmap --global`. I noticed I had to run `gmap heat` to generate a cache folder and db locally before running `gmap heat tui`, otherwise nothing shows up.
It's scary to have the cache folder locally because I could accidently check that in if I don't place it in a .gitignore; is there a better way to handle something like that?
Good shout on the cache folder. Right now it just lives locally (.gmap), so yeah adding it to .gitignore is the way to go for now. I’ve been thinking about better ways to handle it. maybe an XDG-compatible path or something configurable. If a better idea comes up, I’ll def switch to it.
Thanks for trying it out!
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.
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
I'm not sure there's anything better than manually tracing hotpaths and making changes. Maybe an INTERNALS.md to document architecture would be nice. And reading through recent PRs too. Curious about your approach.
It’s still early, but I’d like to evolve it to make those insights more actionable, maybe even link recent PRs, show how files evolved, or highlight ownership boundaries. Feedback like yours helps shape that, so thanks again.