You hit the nail on the head; that is absolutely the biggest bottleneck.

Right now, I am using Python's multiprocessing to parallelize the commit traversal, and the scanner actively ignores standard binary and media file extensions to keep memory overhead in check. On mid-sized repositories, it holds up nicely. However, on massive monorepos with years of heavy history, it will definitely lag behind compiled Go tools.

To mitigate this for daily workflows, I added a --depth flag so developers can limit the scan to the last N commits (e.g., just checking their current feature branch history before pushing). Profiling and optimizing the traversal tree for massive repos is my next major architectural focus.

I haven't published formalized benchmarks yet, but to be completely transparent: keychase will not beat Gitleaks or TruffleHog in raw execution speed. They are highly optimized Go binaries, and pure Python has its limits there.

The core differentiator is the developer experience for Python-native teams. You don't have to pull a Docker image or install system binaries—it just lives in your requirements.txt or pre-commit pipeline.

Regarding false positives: Currently, keychase relies strictly on 78+ regex detectors, so it carries the standard regex false-positive rate. TruffleHog is vastly superior in this regard right now because they do active API verification. To close that gap, my roadmap includes building entropy-based detection for unknown secrets and adding optional active-verification pings.