tsdb: more efficient sorting of postings read from WAL at startup

[bboreham]

This was something I noticed in passing.

Benchmark stats:

name                                                old time/op    new time/op    delta
MemPostings_ensureOrder/many_values_per_label-4        568ms ± 2%     567ms ± 2%      ~     (p=0.690 n=5+5)
MemPostings_ensureOrder/few_values_per_label-4         649ms ± 0%     659ms ± 5%      ~     (p=0.190 n=4+5)
MemPostings_ensureOrder/few_refs_per_label_value-4    28.5ms ± 3%    21.5ms ± 2%   -24.53%  (p=0.008 n=5+5)

name                                                old alloc/op   new alloc/op   delta
MemPostings_ensureOrder/many_values_per_label-4       24.0MB ± 0%     0.0MB ± 1%   -99.91%  (p=0.008 n=5+5)
MemPostings_ensureOrder/few_values_per_label-4        24.0MB ± 0%     0.0MB ± 0%   -99.90%  (p=0.016 n=5+4)
MemPostings_ensureOrder/few_refs_per_label_value-4    24.0MB ± 0%     0.0MB ± 6%  -100.00%  (p=0.008 n=5+5)

name                                                old allocs/op  new allocs/op  delta
MemPostings_ensureOrder/many_values_per_label-4        1.00M ± 0%     0.00M ± 0%  -100.00%  (p=0.008 n=5+5)
MemPostings_ensureOrder/few_values_per_label-4         1.00M ± 0%     0.00M ±12%  -100.00%  (p=0.008 n=5+5)
MemPostings_ensureOrder/few_refs_per_label_value-4     1.00M ± 0%     0.00M ± 0%  -100.00%  (p=0.008 n=5+5)

Most of the benefit comes from avoiding slice-to-interface allocation, by pulling the seriesRefSlice out of the loop, so the compiler doesn't allocate a new one on the heap every time.

The second commit to use a pointer type in the Pool reduces allocations two more orders of magnitude: this is almost invisible in benchmark timings after the first commit, but I couldn't leave it with a staticcheck warning :-)

Removed a comment that said fixing this has a performance penalty: not borne out by benchmarks.

Since benchstat rounded the numbers, the first commit goes to 987 allocs/iter, and the second to 9.

[metalmatze]

Fantastic, as always! 💯

[roidelapluie]

/prombench v2.34.0

[prombot]

⏱️ Welcome to Prometheus Benchmarking Tool. ⏱️

Compared versions: PR-10500 and v2.34.0

After successful deployment, the benchmarking metrics can be viewed at:

• Prometheus Meta
• Prombench Dashboard
• Grafana Explorer, Loki logs

Other Commands:
To stop benchmark: /prombench cancel
To restart benchmark: /prombench restart v2.34.0

[roidelapluie]

This PR has the memory leak apparently. I am checking if it is the first one.

[bboreham]

It seems to take several hours to kick in, which is interesting if it's caused by a change that only runs during startup.

[roidelapluie]

/prombench cancel

[prombot]

Benchmark cancel is in progress.