Rust port of 'metrics' for libextra

[graydon]

A clone of the 'metrics' package would be useful for instrumentation. We have enough stuff we want to monitor that it'd be good to standardize the interface.

https://github.com/codahale/metrics
https://github.com/rcrowley/go-metrics

Currently I'm growing some ad-hoc pieces of this in extra::stats, the std::test benchmarking code, and the log-bin statistics counters in the new GC. Consolidating that and copying best practice structure (eg. properly separating collecting, aggregating and reporting) from the designs of other metrics libraries would be good.

Depends on #7458

[graydon]

Note: there are also new stat counters in @brson's scheduler work. And rustc has a number of internal counters for phase timing and size measurements.

[graydon]

https://github.com/omergertel/pyformance is another port

[graydon]

Also note that @tkuehn has been hacking up a metrics library for servo over in https://github.com/mozilla/servo/blob/master/src/components/util/time.rs so we should coordinate work with requirements there.

[graydon]

Other areas we have counters in rustc:

• trans stats: https://github.com/mozilla/rust/blob/master/src/librustc/middle/trans/common.rs#L89
• metadata stats: https://github.com/mozilla/rust/blob/master/src/librustc/metadata/encoder.rs#L1644
• borrowck stats: https://github.com/mozilla/rust/blob/master/src/librustc/middle/borrowck/mod.rs#L86
• time() (for time-passes): https://github.com/mozilla/rust/blob/master/src/librustc/util/common.rs#L21

There may be others. Will keep digging.

[brson]

Not 0.8

[flaper87]

Triage bump, still lot to do here and a valid bug.

[flaper87]

Also, since libextra is being split into standalone packages, this metrics work should probably live in libmetrics or elsewhere.

[evnm]

What's the status of this issue? I notice that stats.rs now resides in libtest, but the domain-specific counter and timing support code in rustc is still disjointed.

Maybe this is ok? Even with the current state of affairs, you could imagine someone building as a crate an application metrics library atop test::stats, integrating ideas from Dropwizard's Metrics, HdrHistogram, etc. Would this be undesirable? It's unclear whether that kind of full-featured metrics library was the intended outcome of this issue or rather a collection of traits and utilities with which to write one.