Hey, so as described here:
http://wrla.ch/blog/2015/11/perfherder-onward/
... I recently added tracking for Firefox installer size inside
Perfherder. This should let us track how bloated (or not) Firefox is on
our various supported platforms, on a per-commit basis:
https://treeherder.mozilla.org/perf.html#/graphs?series=[mozilla-inbound,4eb0cde5431ee9aeb5eb14512ddb3da6d4702cf0,1]&series=[mozilla-inbound,80cac7ef44b76864458627c574af1a18a425f338,1]&series=[mozilla-inbound,0060252bdfb7632df5877b7594b4d16f1b5ca4c9,1]
As I mentioned in the blog post, it's now *very* easy (maybe too easy?
heh) to submit "performance" (read: quantitative) data for any job
reporting to treeherder by outputting a line called "PERFHERDER_DATA" to
the log.
Is there anything we could be tracking as part of our build or test jobs
that we should be? Build times are one thing that immediately comes to
mind. Is there anything else?
In order to be a good candidate for measurement in this kind of system,
a metric should be:
1. Relatively deterministic.
2. Something people actually care about and are willing to act on, on a
per-commit basis. If you're only going to look at it once a quarter or
so, it doesn't need to be in Perfherder.
Anyway, just thought I'd open the floor to brainstorming. I'd prefer to
add stuff incrementally, to make sure Perfherder can handle the load,
but I'd love to hear all your ideas.
Will
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
