go-gorm / go-gorm/cli

perf: pre-compile glob patterns in config filter matching

Open
#58 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
108
Forks
15
PR merge metrics
No merged PRs in 30d

Description

## Summary

`matchAnyName` in `generator.go:148-158` performs shell glob matching for every pattern on every interface/struct during config filtering:

```go
matchAnyName := func(name string, patterns []any) bool {
name = filePkgPath + "." + stripGeneric(name)
for _, p := range patterns {
if stripGeneric(fmt.Sprint(p)) == name {
return true
}
if ok, _ := filepath.Match("*"+stripGeneric(fmt.Sprint(p)), filepath.Base(name)); ok {
return true
}
}
return false
}
```

Each call to `filepath.Match` parses the glob pattern from scratch. For 100 structs × 5 patterns, that's 500+ glob matches. `fmt.Sprint(p)` is also called twice per pattern iteration.

## Proposed Fix

Pre-compile patterns once before the filtering loop:

```go
type compiledPattern struct {
exact string // for exact match
glob string // for filepath.Match
}
```

Compile all patterns once, then match against the compiled list. Also cache `fmt.Sprint(p)` results.

## Impact

Minor — only noticeable in monorepos with many structs/interfaces and many filter patterns. The O(n × m) matching is fine for typical use (5–20 types, 1–3 patterns), but pre-compilation is the right pattern for correctness and makes the code cleaner.

## Note

The outer loop at `generator.go:117-135` does O(files × configFiles) prefix matching. For typical CLI usage this is negligible, but if the codebase grows to support large monorepos with many config files, consider sorting config paths and using binary search for prefix matching.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.