chore(metric_extraction): Optimize labels result

[shantanualsi]

What this PR does / why we need it:

The current implementation of LabelsResult method used in critical flows within metrics_generation, pipeline, etc fetched UnsortedLabels in the buffer for each category (ParsedLabel, structured metadata, StreamLabel) and individually sorts them. The sorted results are cached in memory. Majority of resource utilisation here was on sorting labels of each of the categories and creating a copy from buffer.

The new implementation fetches all Unsorted Labels and sorts them collectively and caches the result first. Individual categories are segregated after caching.

(notice the labels.Copy is gone in the newer implementation in memory profile)

Results:

BenchmarkStreamLineSampleExtractor_Process

Cpu before:

Cpu after

Mem before:

Cpu after:

BenchmarkReadWithStructuredMetadata: create a memchunk and iterate on it

cpu and memory

benchstat result -

Overall Summary from the results:

Excluding some variability in the measurements, The new implementation is at least 28% faster than the older one with a dramatic 89% improvement in memory usage. Each run also took 79.8% fewer allocs/op than the old implementation.

Which issue(s) this PR fixes:

Special notes for your reviewer:

Checklist

• [x] Reviewed the CONTRIBUTING.md guide (required)
• [x] Documentation added
• [x] Tests updated
• [ ] Title matches the required conventional commits format, see here
  • Note that Promtail is considered to be feature complete, and future development for logs collection will be in Grafana Alloy. As such, feat PRs are unlikely to be accepted unless a case can be made for the feature actually being a bug fix to existing behavior.
• [ ] Changes that require user attention or interaction to upgrade are documented in docs/sources/setup/upgrade/_index.md
• [ ] If the change is deprecating or removing a configuration option, update the deprecated-config.yaml and deleted-config.yaml files respectively in the tools/deprecated-config-checker directory. Example PR

[shantanualsi]

Thanks! Will address the comments separately in a separate PR.

[shantanualsi]

To address the comments here, re-using the slices as expected seem to increase in-use memory as opposed to initializing the slices for parsed, SM and stream labels. https://github.com/grafana/loki/compare/main...shantanu/improve-iterator-optimization

Also, the call func (l labelsResult) Labels() is now only used in tests, not in the critical path anymore. We don't need flattenLabels as all the labels are stored alreayd in the buffer and then sorted.