Replace usages of io.micrometer.core.instrument.Tags with Iterable<Tag>

[DanielThomas]

io.micrometer.core.instrument.Tags turns out to be a poor intermediate representation of Iterable<Tag>. In addition to being immutable and requiring a new instance for every call, it sorts and deduplicates elements on every operation which can lead to some significant CPU overhead on hot paths and/or with large numbers of tags:

https://github.com/micrometer-metrics/micrometer/blob/a56b968ba5b3db9b5e4a4feac813080783a16f5f/micrometer-core/src/main/java/io/micrometer/core/instrument/Tags.java#L43-L47

All of the tags builder methods call Tags::and and there's no optimization for an initially empty state or the passed Iterable<? extends Tag> being a Tags instance, so you pay that overhead when finally adding the tags, no matter how the tags are constructed:

• https://github.com/micrometer-metrics/micrometer/blob/a56b968ba5b3db9b5e4a4feac813080783a16f5f/micrometer-core/src/main/java/io/micrometer/core/instrument/AbstractTimerBuilder.java#L54-L80
• https://github.com/micrometer-metrics/micrometer/blob/a56b968ba5b3db9b5e4a4feac813080783a16f5f/micrometer-core/src/main/java/io/micrometer/core/instrument/Gauge.java#L108-L134

This replaces all direct usages of Tags with Iterable<Tag> and avoids calling the tag builder methods more than once.

[DanielThomas]

Reported upstream too micrometer-metrics/micrometer#4052

[ShivaniSara]

Is the CPU overhead issue due to Tags::and resolved after this change? I am still seeing this issue with micrometer-registry-dynatrace.version 1.11.5

[DanielThomas]

What release of DGS @ShivaniSara? This that might change after 8.5.0 and the switch to Spring GraphQL under the covers.

[ShivaniSara]

I am sorry I am not clear on the DGS release. I was just using 'micrometer-registry-dynatrace.version' to collect metrics and was able to see in Dynatrace that Tags::and is consuming alot. I see in Counter class:

public Builder tags(Iterable tags) {
this.tags = this.tags.and(tags);
return this;
}

[DanielThomas]

Oh I see what you're asking. Yes, this change addressed the overhead, reducing the overhead to a single sort per meter construction. Using this pattern is definitely the way to go until the upstream issue is addressed.