telemetry: Add unit 'score' to 'mostly_smooth' metric.

telemetry: Add unit 'score' to 'mostly_smooth' metric.

The mostly_smooth metric has no unit and therefore shows lower values as an
improvement in results.html. Adding 'score' as the unit to fix this.

R=fmeawad@chromium.org
BUG=

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=244057

[ernstm, 2014-01-03 19:29:20]

PTAL

[fmeawad, 2014-01-03 19:39:46]

LGTM

https://codereview.chromium.org/124103002/diff/1/tools/perf/metrics/smoothnes...
File tools/perf/metrics/smoothness.py (right):

https://codereview.chromium.org/124103002/diff/1/tools/perf/metrics/smoothnes...
tools/perf/metrics/smoothness.py:82: results.Add('mostly_smooth', 'score', 1.0
if percentile_95 < 19.0 else 0.0)
Would '%' also work? is it a percentile?

[ernstm, 2014-01-04 01:08:47]

https://codereview.chromium.org/124103002/diff/1/tools/perf/metrics/smoothnes...
File tools/perf/metrics/smoothness.py (right):

https://codereview.chromium.org/124103002/diff/1/tools/perf/metrics/smoothnes...
tools/perf/metrics/smoothness.py:82: results.Add('mostly_smooth', 'score', 1.0
if percentile_95 < 19.0 else 0.0)
On 2014/01/03 19:39:47, fmeawad-cr wrote:
> Would '%' also work? is it a percentile?

It is a binary value (0 or 1), so score seemed the best option from what we
already have in unit-info.json. Another reason why percent would not work is
that it is reported as 'lower is better'.

[commit-bot: I haz the power, 2014-01-07 17:36:19]

No LGTM from a valid reviewer yet. Only full committers are accepted.
Even if an LGTM may have been provided, it was from a non-committer or
a lowly provisional committer, _not_ a full super star committer.
See http://www.chromium.org/getting-involved/become-a-committer
Note that this has nothing to do with OWNERS files.

[ernstm, 2014-01-07 22:56:51]

Quinten, can you please take a quick look at this?

[qyearsley, 2014-01-08 02:35:32]

On 2014/01/07 22:56:51, Manfred Ernst wrote:
> Quinten, can you please take a quick look at this?

LGTM.

This would indeed work to make it so that transitions from 0 to 1 would not be
marked as regressions. Although, 'score' isn't a super-descriptive units name.
I'm not sure if it's likely to cause any confusion though. If it might avoid
confusion, you could use 'boolean' or 'binary' or something like that for the
unit name, and add this unit name to tools/perf/unit-info.json.

[ernstm, 2014-01-09 23:56:56]

On 2014/01/08 02:35:32, qyearsley wrote:
> On 2014/01/07 22:56:51, Manfred Ernst wrote:
> > Quinten, can you please take a quick look at this?
> 
> LGTM.
> 
> This would indeed work to make it so that transitions from 0 to 1 would not be
> marked as regressions. Although, 'score' isn't a super-descriptive units name.
> I'm not sure if it's likely to cause any confusion though. If it might avoid
> confusion, you could use 'boolean' or 'binary' or something like that for the
> unit name, and add this unit name to tools/perf/unit-info.json.

I've thought about 'boolean'/'binary', but when the values are averaged for
multiple pages, the result will not be binary any more. It will be a value
between 0.0 and 1.0. That's why I think 'score' is still a better unit for this.

[commit-bot: I haz the power, 2014-01-10 00:07:55]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ernstm@chromium.org/124103002/1

[qyearsley, 2014-01-10 00:10:10]

On 2014/01/09 23:56:56, Manfred Ernst wrote:
> On 2014/01/08 02:35:32, qyearsley wrote:
> > On 2014/01/07 22:56:51, Manfred Ernst wrote:
> > > Quinten, can you please take a quick look at this?
> > 
> > LGTM.
> > 
> > This would indeed work to make it so that transitions from 0 to 1 would not
be
> > marked as regressions. Although, 'score' isn't a super-descriptive units
name.
> > I'm not sure if it's likely to cause any confusion though. If it might avoid
> > confusion, you could use 'boolean' or 'binary' or something like that for
the
> > unit name, and add this unit name to tools/perf/unit-info.json.
> 
> I've thought about 'boolean'/'binary', but when the values are averaged for
> multiple pages, the result will not be binary any more. It will be a value
> between 0.0 and 1.0. That's why I think 'score' is still a better unit for
this.

Alright, makes sense. "score" is already in unit-info.json with improvement
direction as "up", so this would be fine :-)

[commit-bot: I haz the power, 2014-01-10 02:54:43]

Change committed as 244057