fix metric sort error

[linuxgcc]

#1442

[ArthurSens]

Although I agree that sometimes humans debug exposed metrics by manually looking the /metrics endpoint, I believe this endpoint it focused on metrics being scraped by Prometheus. Prometheus doesn't care about the number ordering 🤷

If we introduce a regex sort, I wonder how much are we sacrificing in performance for this change. Do you mind doing some benchmarking and posting the results here?

[linuxgcc]

@ArthurSens Sorry, I don't have time recently, benchmark has been completed.

1 . touch such file prometheus/internal/metric_sort_test.go 2. with out reg sort benchmark

[root@trace client_golang]# go test -bench="BenchmarkSort" -benchtime=100x -benchmem ./prometheus/internal
goos: linux goarch: amd64 pkg: github.com/prometheus/client_golang/prometheus/internal cpu: Intel Xeon Processor (Cascadelake) BenchmarkSort-16 100 2020 ns/op 265 B/op 8 allocs/op PASS ok github.com/prometheus/client_golang/prometheus/internal 0.012s

4. with reg sort benchmark

[root@trace client_golang]# go test -bench="BenchmarkSort" -benchtime=100x -benchmem ./prometheus/internal
goos: linux goarch: amd64 pkg: github.com/prometheus/client_golang/prometheus/internal cpu: Intel Xeon Processor (Cascadelake) BenchmarkSort-16 100 88625 ns/op 52093 B/op 626 allocs/op PASS ok github.com/prometheus/client_golang/prometheus/internal 0.022s

[root@trace client_golang]#

It can be seen from the above comparison that the comparison of 16-core CPU data before and after using regular expressions takes no more than 0.1ms

[ArthurSens]

We can also see a huge increase in memory allocation though 😱 , 8 allocations per operation up to 626 allocations. The allocated memory also increased a lot

[bwplotka]

Sounds like we have to reject this, sorry! This is an intended behaviour.