perf: avoid allocations with (*regexp.Regexp).MatchString

[Juneezee]

what

Replace (*regexp.Regexp).Match([]byte(...)) with (*regexp.Regexp).MatchString

why

We should use (*regexp.Regexp).MatchString instead of (*regexp.Regexp).Match([]byte(...)) when matching string to avoid unnecessary []byte conversions and reduce allocations. A one-line change for free performance gain.

Example benchmark:

func BenchmarkMatch(b *testing.B) {
	for i := 0; i < b.N; i++ {
		if match := branchRegex.Match([]byte("main")); !match {
			b.Fail()
		}
	}
}

func BenchmarkMatchString(b *testing.B) {
	for i := 0; i < b.N; i++ {
		if match := branchRegex.MatchString("main"); !match {
			b.Fail()
		}
	}
}

goos: linux
goarch: amd64
pkg: github.com/runatlantis/atlantis/server/core/config cpu: AMD Ryzen 7 PRO 4750U with Radeon Graphics
BenchmarkMatch-16          	 8269699	       141.4 ns/op	       4 B/op	       1 allocs/op
BenchmarkMatchString-16    	14298446	        95.81 ns/op	       0 B/op	       0 allocs/op
PASS
ok  	github.com/runatlantis/atlantis/server/core/config	2.784s

tests

go test ./server/core/config
ok  	github.com/runatlantis/atlantis/server/core/config	0.024s

references

[jamengual]

@GenPage

[nitrocode]

Fwiw I agree with this change.

I see some references online that also point to a performance gain

They are very similar. while slices like []byte are mutable (you can change values in the underlying array) strings are immutable.
Internally []byte consists of a length, capacity (both int values) and a pointer to the first element [1]. Strings only consist of the length and the pointer because capacity and length are always the same since strings are immutable.

What are the dangers of casting between them?

Wasted performance and memory

Why are regexp functions even relevant for []byte?

Because it is cheap. The function can easily return a sub-slice without copying any data.

https://groups.google.com/g/golang-nuts/c/YmiYPe7lako?pli=1

[jamengual]

/cherry-pick release-0.26

[jamengual]

@Juneezee Thanks for the contribution