#573 optimize filtering algorithm for DropwizardExports

[vladimir-bukhtoyarov]

The intention of this optimization has been described there #573 (comment)

[brian-brazil]

Do you have benchmarks to demonstrate how useful this is?

Also please use explicit imports, it's hard to follow what is what otherwise.

[vladimir-bukhtoyarov]

I can not imagine how to write the benchmark here. The penalty of filtering depends on two factors:

• Complexity of filter itself.
• Amount of metrics in the registry.

This pull request allows applying filter only one for each metric, filter does not need to be applied on each reporting cycle. For example, if we have 3 regular expressions in the filter, and 5000 metrics in the registry, then 15000 regexps are not executed on each reporting cycle, because pre-filtering of registry makes this work unnecessary. A huge metric-registry with thousands of metrics is a typical case for systems like Cassandra or Kafka, and in the same time usually we need to implement complex filtering for this kind of applications because we do not want to report so huge dataset to the monitoring database.

[brian-brazil]

It'd be good to have some rough idea, for example if it turns out that other processing is substantially larger then there's not much point in having this from a complexity standpoint.

I also presume it's safe to assume that filters don't vary over time?

[vladimir-bukhtoyarov]

Looks I can just continue to wrap the registry by decorator before passing to the collector.