Rework labels benchmarks to not misrepresent the relative speed of labels and no labels.

[jdmarshall]

I realized today that I've been saying something about the labels code that is not true and it's down to how the tests are being run.

The problem is that when we run the benchmark with no labels, we call the benchmark n times and show that as the runtime for Counter.inc(), but when we measure the performance of labels, instead of testing one set of labels we are testing a combinatorial set of labels and so each test run is not measuring Counter.inc() but instead m^k runs of Counter.inc.

So any time I increase the number of labels or the cardinality of them it looks like the new test runs slower but it's testing more values.

I'm still working out how to fix this. I made a couple pattern changes in a new benchmark, benchmarks/defaultMetrics.js but it'll need more than this.

[jdmarshall]

Investigate adjusting the loop to run the same number of iterations even if the fixtures aren't used for the given test, so that all runs call the functions the same number of times regardless of the input variability.

Eg, 20 calls of 0 labels, 5 calls of 2x2 labels.

[LuffySama-Dev]

Hi, I'd like to contribute to this if it's still available. My plan is to make each benchmark invocation perform one metric operation and cycle through the label combinations, so the comparisons use the same workload. I'd also add tests to check the operation count and that all combinations are covered.

Could you assign this to me if nobody else is working on it?