The test results do not match the document, which says slices is faster, but the test found that sort is faster.

Which document are you referring to?

CC @eliben

That's not a great benchmark, because it just calls the sorting function over and over again on the same slice. After the first call, the slice will be fully sorted. So you aren't really testing how long it takes to sort, you are testing how long it takes to determine that the slice is already sorted.

There are some existing benchmarks in slices/sort_benchmark_test.go and sort/sort_test.go that don't have that problem.

Document in https://pkg.go.dev/sort@master#Strings
I use the following benchmarks to sort different slices in each loop：

Note: consider using the new slides. Sort function, which runs faster

This document is easily understood as calling slices.Sort on the same slice (using [] string as an example) is faster than calling sort.Strings.

I think this part of the document should be changed to: "Note: Consider using the newer slices.Sort function to run faster on Not sorted slices", It's much less likely to be misunderstood.

Which document are you referring to?

I think author means "documentation".

In my measurements, slices.Sort is 15-20% faster on a shuffled slice of strings (this is what I get by running the in-tree benchmarks @iant mentioned). For a presorted slice, I see measurement noise - either function is ~1% faster depending on the run.

Both functions end up in the same code-generated implementation, and the difference between them is the cost of dispatch (StringSlice interface for sort.Strings and generic dispatch for cmp.Ordered for slices.Sort) so I don't really see why sorting a sorted slice would be consistently faster for sort.Strings.

@zhangyunhao116

For this benchmark, the sort.Strings is slightly faster.

func sortedStrings() []string {
	const N = 10000
	x := make([]string, N)
	for i := 0; i < N; i++ {
		x[i] = strconv.Itoa(i)
	}
	slices.Sort(x)
	return x
}

func BenchmarkSlices(b *testing.B) {
	x := sortedStrings()
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		slices.Sort(x)
	}
}

func BenchmarkSort(b *testing.B) {
	x := sortedStrings()
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		sort.Strings(x)
	}
}

We can see the diff from its flame graph. I think the reason is that the slices use cmp.Less, which consumes too much CPU on the isNaN. IMO, we can optimize this pattern in the compiler, there are many types like the string that don't require the isNaN.

"IMOP, we can optimize this pattern in the compiler, there are many types like the string that don't require the isNaN."
Can golang just add compile time type check (rust called "Zero Cost Abstractions") to only check isNan with float32 or float64? Or the compiler can transform runtime type check to compile time type check?

That just looks like a missing optimization. x==x should always return true for strings, and it doesn't.

func f(x string) bool {
	return x == x
}

That should compile to the equivalent of return true, but it doesn't. It ends up calling memequal (which does shortcut immediately to return true, but the call itself is still there).

For this benchmark, the sort.Strings is slightly faster.

func sortedStrings() []string {
	const N = 10000
	x := make([]string, N)
	for i := 0; i < N; i++ {
		x[i] = strconv.Itoa(i)
	}
	slices.Sort(x)
	return x
}

func BenchmarkSlices(b *testing.B) {
	x := sortedStrings()
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		slices.Sort(x)
	}
}

func BenchmarkSort(b *testing.B) {
	x := sortedStrings()
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		sort.Strings(x)
	}
}

Yes, this data is different so I see slightly different results. sort.Strings is faster by 1-2%

@randall77 makes a good point about how this can be fixed.

In the meantime, I'm not sure whether the doc comment should be modified. The new slices.Sort is certainly much faster on "real" inputs; it seems like for some subset of pre-sorted inputs it can be slightly slower. We could qualify the comment from "runs faster" to "runs faster in most cases", but I'm not sure it's worth it.

Change https://go.dev/cl/503795 mentions this issue: cmd/compile: optimize s==s for strings

Change https://go.dev/cl/503815 mentions this issue: slices: add sort benchmark for sorted strings

I've updated the issue title to better reflect the current understanding. @randall77 's https://go.dev/cl/503795 fixes this, but we're not sure whether this fix is worth it for inclusion in 1.21 or will have to wait for 1.22

In the meantime, my inclination is not to do anything about the documentation, given the special circumstances where it's inaccurate (only for sorted inputs, and even then, only for some sorted inputs). Happy to hear other opinions