Feature/contains iterate by index

[lennon-guan]

Refactor Contains function to improve performance by using index iteration over collection

[lennon-guan]

// Benchmark Code & Result
package lo

import "testing"

func oldContains[T comparable](collection []T, element T) bool {
	for _, item := range collection {
		if item == element {
			return true
		}
	}
	return false
}

type containsTestStruct struct {
	A, B, C, D int
	E, F       string
}

var (
	containsInts    = []int{1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
	containsStrings = []string{"1", "2", "3", "4", "5", "6", "7", "8", "9", "10"}
	containsStructs = []containsTestStruct{{}, {}, {}, {}, {}, {}, {}, {}, {}, {A: 1}}
)

func doBenchmark[T comparable](b *testing.B, collection []T, fn func([]T, T) bool) {
	element := collection[len(collection)-1]
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		fn(collection, element)
	}
}

func BenchmarkOldContainsInt(b *testing.B) {
	doBenchmark(b, containsInts, oldContains[int])
}

func BenchmarkContainsInt(b *testing.B) {
	doBenchmark(b, containsInts, Contains[int])
}

func BenchmarkOldContainsString(b *testing.B) {
	doBenchmark(b, containsStrings, oldContains[string])
}

func BenchmarkContainsString(b *testing.B) {
	doBenchmark(b, containsStrings, Contains[string])
}

func BenchmarkOldContainsStruct(b *testing.B) {
	doBenchmark(b, containsStructs, oldContains[containsTestStruct])
}

func BenchmarkContainsStruct(b *testing.B) {
	doBenchmark(b, containsStructs, Contains[containsTestStruct])
}

//result

goos: windows
goarch: amd64
pkg: github.com/samber/lo
cpu: AMD Ryzen 7 5800H with Radeon Graphics         
BenchmarkOldContainsInt-16       	235373313	         5.196 ns/op	       0 B/op	       0 allocs/op
BenchmarkContainsInt-16          	232900494	         5.139 ns/op	       0 B/op	       0 allocs/op
BenchmarkOldContainsString-16    	127452003	         9.454 ns/op	       0 B/op	       0 allocs/op
BenchmarkContainsString-16       	174648490	         6.784 ns/op	       0 B/op	       0 allocs/op
BenchmarkOldContainsStruct-16    	20864157	        54.47 ns/op	       0 B/op	       0 allocs/op
BenchmarkContainsStruct-16       	26957204	        44.76 ns/op	       0 B/op	       0 allocs/op
PASS
ok  	github.com/samber/lo	10.777s

[samber]

Wow. I didn't expect a 30% speed-up!!

Thanks for the tips!

[andig]

With SliceToChannel I'm really wondering what's being sent down to the channel. If that is not an allocated copy, then the semantics of the functions should have changed by this PR. If it is, I'm wondering where the speedup comes from?

With IndexOf I'm wondering why the compiler shouldn't recognize that the comparison is a read-only operation and just not do the allocation?

Every time I think I understand go I find out not...

[andig]

Since I was curious I ran the contains benchmarks on Darwin:

goos: darwin
goarch: arm64
                 │   old.txt   │               new.txt                │
                 │   sec/op    │    sec/op     vs base                │
ContainsInt-8      5.370n ± 6%   5.325n ±  0%   -0.82% (p=0.045 n=10)
ContainsString-8   7.320n ± 5%   7.224n ±  5%        ~ (p=0.210 n=10)
ContainsStruct-8   26.93n ± 1%   19.00n ± 11%  -29.44% (p=0.000 n=10)
geomean            10.19n        9.009n        -11.61%

Allocs:

goos: darwin
goarch: arm64
                 │   old.txt   │              new.txt               │
                 │   sec/op    │   sec/op     vs base               │
ContainsInt-8      5.320n ± 1%   5.316n ± 0%        ~ (p=0.411 n=6)
ContainsString-8   7.271n ± 2%   7.246n ± 1%        ~ (p=0.589 n=6)
ContainsStruct-8   26.61n ± 1%   18.91n ± 5%  -28.96% (p=0.002 n=6)
geomean            10.10n        8.996n       -10.90%

                 │   old.txt    │              new.txt               │
                 │  allocs/op   │ allocs/op   vs base                │
ContainsInt-8      0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=6) ¹
ContainsString-8   0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=6) ¹
ContainsStruct-8   0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=6) ¹
geomean                       ²               +0.00%               ²
¹ all samples are equal
² summaries must be >0 to compute geomean

Seems they are identical- so it would not be reduced number of allocations we're seeing here?