Part I · Day One · The honest performance page · p. 20–21
Yes, somewhat, in specific places
Here is exactly where, with numbers, so you can decide rather than find out.
It is week three. You stage four files and the hook runs. If that moment costs nine seconds, forty times a day, somebody will invent a bypass. Performance is where security tooling adoption actually dies — not in the patient evaluation week.
| Scene | What you feel |
|---|---|
| One 19-line Python file, twelve built-ins + one plugin | 28–35 ms total; the external plugin is roughly two-thirds |
| Built-in (Rust, in-process) | ~1,000–5,000 files / second |
| External (subprocess) | ~50–200 files / second |
| Large tree, ~5,000 files, built-in set | Acquisition ~2.5 s · extract ~1.8 s · scan ~30–35 s |
| Same tree, ~10 external plugins | ~2–3 minutes |
Built-in scanners scan a large repository in about half a minute. Ten external plugins make it four to six times slower. Choose your plugins like you choose dependencies.
Five habits that keep week-three you from mutinying
- Scan the diff, not the tree. git diff main --name-only | xargs securegit scan, or scan --staged.
- Configure skip_paths once, properly. Most first-time “this is slow” reports are a scan of a dependency directory.
- Built-in scanners for the hot path. Save external plugins for scheduled deep scans.
- Match the plugin to the stack. A Python security scanner on a Rust repository costs process-spawn time on every file and finds nothing.
- Deep scan on a schedule, not on every commit.
What is not fast yet, and is known
- File walking is sequential. PLANNED — parallel file processing.
- There is no incremental cache. Every scan rescans everything in scope. PLANNED.
- No --jobs flag yet. PLANNED.
- Very large repositories (over a gigabyte) are slow. Use skip_paths aggressively and scan the diff.