Benchmarks
Philosophy
Section titled “Philosophy”gogenfilter is designed for linters and static analysis tools where detection overhead must be negligible. The two-phase architecture (filename first, content only when needed) ensures most checks complete with zero I/O.
Results
Section titled “Results”Benchmarked on Go 1.26, AMD Ryzen AI MAX+ 395. Results may vary by hardware.
Summary
Section titled “Summary”| Benchmark | ns/op | B/op | allocs/op | |
|---|---|---|---|---|
| Filter (enabled) | 69 | 92 | 0 | |
| Filter (disabled) | 1.2 | 0 | 0 | |
| Filename detection (Phase 1) | 14 | 0 | 0 | |
| Per-generator check (avg) | ~6 | 0 | 0 | |
MatchPattern (doublestar **) | 72 | 0 | 0 | |
| DetectReason (filename) | 353 | 632 | 4 | |
| DetectReason (content) | 693 | 680 | 5 | |
| Error construction | 2 | 0 | 0 | |
| errors.Is matching | 9 | 0 | 0 |
Filter
Section titled “Filter”The primary API. Full end-to-end detection including filesystem access.
Filter/enabled 69 ns/op 92 B/op 0 allocs/opFilter/disabled 1.2 ns/op 0 B/op 0 allocs/opA disabled filter is essentially a branch prediction — 1.2 nanoseconds. An enabled filter with a known-generated file completes in ~69ns with zero heap allocations.
Phase 1: Filename Detection
Section titled “Phase 1: Filename Detection”Phase 1: filename-based detection (zero I/O). This is the fast path — a single scan of the filename against the detector table. No file reads, no content parsing.
Filename phase 14 ns/op 0 B/op 0 allocs/opThis benchmarks the internal filename-only check. Results are exact-matched against known generated-file patterns (e.g., models.go, *.sql.go, _templ.go, .pb.go, wire_gen.go, _moq.go, _mock.go, mock_*.go).
Per-Generator Checks
Section titled “Per-Generator Checks”Individual Is*Generated functions. Four of them (IsSQLCGenerated, IsTemplGenerated, IsGoEnumGenerated, IsProtobufGenerated) check both filename patterns and content markers. The remaining seven check content only.
IsGenericGenerated 5.0 ns/op 0 B/op 0 allocs/opIsSQLCGenerated 5.9 ns/op 0 B/op 0 allocs/opIsProtobufGenerated 7.0 ns/op 0 B/op 0 allocs/opAll under 7 nanoseconds with zero allocations.
DetectReason
Section titled “DetectReason”Variadic detection across multiple filter options:
DetectReason/filename_only 353 ns/op 632 B/op 4 allocs/opDetectReason/content_based 693 ns/op 680 B/op 5 allocs/opDetectReason/not_filtered 614 ns/op 680 B/op 5 allocs/opHigher cost than the per-generator checks because it iterates all enabled detectors and performs content matching. Still sub-microsecond.
DetectReasonReader
Section titled “DetectReasonReader”Same as DetectReason but reads from an io.Reader:
DetectReasonReader/sqlc_filename 517 ns/op 1288 B/op 8 allocs/opDetectReasonReader/not_filtered 812 ns/op 1272 B/op 9 allocs/opIncludes the cost of reading content from the reader.
Pattern Matching
Section titled “Pattern Matching”MatchPattern with different glob patterns via doublestar:
MatchPattern/question 25 ns/op 0 B/op 0 allocs/opMatchPattern/exact 40 ns/op 0 B/op 0 allocs/opMatchPattern/wildcard 46 ns/op 0 B/op 0 allocs/opMatchPattern/doublestar 72 ns/op 0 B/op 0 allocs/opMatchPattern/no_match 77 ns/op 0 B/op 0 allocs/opAll zero-allocation. ** globs are the most expensive at ~72ns — still negligible.
Error System
Section titled “Error System”Error construction and inspection:
NewSQLCConfigError 0.2 ns/op 0 B/op 0 allocs/opNewProjectRootError 1.9 ns/op 0 B/op 0 allocs/opProjectRootErrorIs 7.9 ns/op 0 B/op 0 allocs/opSQLCConfigErrorIs 8.9 ns/op 0 B/op 0 allocs/opProjectRootErrorError 229 ns/op 144 B/op 3 allocs/opSQLCConfigErrorError 284 ns/op 176 B/op 5 allocs/opError construction and errors.Is matching are essentially free. Error() string formatting allocates but is only called when displaying errors.
Reproducing
Section titled “Reproducing”Run the benchmarks yourself:
go test -bench=. -benchmem ./...For stable results, run on a quiet system with CPU frequency scaling disabled.
Live Dashboard
Section titled “Live Dashboard”Historical benchmark trends are tracked automatically on every push to master:
The dashboard shows:
- Time-series charts for all 17 benchmarks
- Commit-level granularity with tooltips showing commit messages
- Automatic regression highlighting when performance degrades >150%
Results above are a point-in-time snapshot (Go 1.26, AMD Ryzen AI MAX+ 395). The dashboard provides continuous, hardware-consistent tracking from CI.