optimize Collector.sanitizeMetricName

[fwbrasil]

Problem

Some libraries resolve Prometheus metrics dynamically and use Collector.sanitizeMetricName for that. Ideally, this method shouldn't be in the hot path but it seems worth optimizing it for libraries that provide dynamic metric resolution like https://github.com/clj-commons/iapetos so the performance penalty isn't a concern for them.

I noticed this issue while profiling an application that uses iapetos. The regex execution is currently the main cost of the application:

Including being the source of a large portion of the invoke interface dispatches:

Solution

Optimize the Collector.sanitizeMetricName method to avoid the regex engine and use a simple for-loop.

Results

I've created a new benchmark for this method. Results:

Before

Benchmark                                             Mode  Cnt    Score    Error  Units
SanitizeMetricNameBenchmark.sanitizeNonSanitizedName  avgt    4  694.406 ± 44.971  ns/op
SanitizeMetricNameBenchmark.sanitizeSanitizedName     avgt    4  486.219 ± 25.100  ns/op

After

Benchmark                                             Mode  Cnt   Score   Error  Units
SanitizeMetricNameBenchmark.sanitizeNonSanitizedName  avgt    4  17.915 ± 0.940  ns/op
SanitizeMetricNameBenchmark.sanitizeSanitizedName     avgt    4  13.730 ± 1.139  ns/op

[fwbrasil]

Hi @fstab, I'm sorry to ping you directly. If you have an opportunity to take a look at this PR, we wanted to know if it's something that seems to make sense for you (it's ok if you can't review/merge atm). If not, we're going to try to optimize it in iapetos. Thank you!

[fstab]

Hi, thanks for the PR. I am planning to have a look this weekend, didn't find the time during the week.

[fstab]

Thanks a lot @fwbrasil. I merged it.