Add guards to metric values; erase bad events/metrics from db

Add guards to metric values; erase bad events/metrics from db

Improves the database by not inserting blatantly erroneous data, and by deleting
any events or metrics which cannot be properly retrieved from the database.
Also make DB take a metric for AddMetric() - this makes it so that we have a
more accurate timestamp since we record the time before the thread-jumping.

BUG=130212
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=157168

[eaugusti, 2012-09-07 23:10:55]

https://chromiumcodereview.appspot.com/10907121/diff/2001/chrome/browser/perf...
File chrome/browser/performance_monitor/database.cc (right):

https://chromiumcodereview.appspot.com/10907121/diff/2001/chrome/browser/perf...
chrome/browser/performance_monitor/database.cc:201: if (!metric.Validate()) {
Should this be a DCHECK?
If this method is getting a bad Metric, then a programmer made a mistake.

https://chromiumcodereview.appspot.com/10907121/diff/2001/chrome/browser/perf...
chrome/browser/performance_monitor/database.cc:207: base::Time timestamp =
clock_->GetTime();
I don't like how Metric has time, but clock_ is still used here. It could just
be because the uncommited dependency, but it would be best if the clock was not
used for Metrics as soon as Metrics are passed into Add*() methods.

https://chromiumcodereview.appspot.com/10907121/diff/2001/chrome/browser/perf...
chrome/browser/performance_monitor/database.cc:362: LOG(ERROR) << "Found bad
metric in database. Erasing the metric from "
We may want to consider moving this to a verbose log. I am imagining the
situation where deprecated or some large chunk of bad data is being accessed.

ps. This comment applies to all the logs of this nature.

https://chromiumcodereview.appspot.com/10907121/diff/2001/chrome/browser/perf...
File chrome/browser/performance_monitor/database_unittest.cc (right):

https://chromiumcodereview.appspot.com/10907121/diff/2001/chrome/browser/perf...
chrome/browser/performance_monitor/database_unittest.cc:68: 
nit: extra space

https://chromiumcodereview.appspot.com/10907121/diff/2001/chrome/browser/perf...
File chrome/browser/performance_monitor/metric.cc (right):

https://chromiumcodereview.appspot.com/10907121/diff/2001/chrome/browser/perf...
chrome/browser/performance_monitor/metric.cc:86: bool Metric::Validate() const {
Should this validate the type too?

[Devlin, 2012-09-10 17:49:14]

https://chromiumcodereview.appspot.com/10907121/diff/2001/chrome/browser/perf...
File chrome/browser/performance_monitor/database.cc (right):

https://chromiumcodereview.appspot.com/10907121/diff/2001/chrome/browser/perf...
chrome/browser/performance_monitor/database.cc:201: if (!metric.Validate()) {
On 2012/09/07 23:10:55, eaugusti wrote:
> Should this be a DCHECK?
> If this method is getting a bad Metric, then a programmer made a mistake.

Not necessarily. If this is a bad Metric, then it is more likely a call returned
a bad value. Perhaps I should have been more verbose in the CL's description,
but blatantly bad values can't always be helped. We've found that we've gotten
CPU usage of negative numbers reported before, page loads in the thousands of
seconds, etc.

A few things on this note. For one, there's not always a guarantee that we can
always fix these. Sometimes, it might be out of our capabilities. I've seen
system calls fail on these things, but clearly we're not going to re-write
those. Another issue is that, even if it is a bug in Chrome's source, the
PerformanceMonitor team can't fix them all (if we have to debug why CPU usage
might return negative on 3 different platforms, heavily diving into
system-specific properties and system calls, it becomes more trouble than it's
worth for the 1% of the time it might return a bad value). Simply ignoring these
bad values is the best solution for the short-term.

https://chromiumcodereview.appspot.com/10907121/diff/2001/chrome/browser/perf...
chrome/browser/performance_monitor/database.cc:207: base::Time timestamp =
clock_->GetTime();
On 2012/09/07 23:10:55, eaugusti wrote:
> I don't like how Metric has time, but clock_ is still used here. It could just
> be because the uncommited dependency, but it would be best if the clock was
not
> used for Metrics as soon as Metrics are passed into Add*() methods.

Done.

https://chromiumcodereview.appspot.com/10907121/diff/2001/chrome/browser/perf...
chrome/browser/performance_monitor/database.cc:362: LOG(ERROR) << "Found bad
metric in database. Erasing the metric from "
On 2012/09/07 23:10:55, eaugusti wrote:
> We may want to consider moving this to a verbose log. I am imagining the
> situation where deprecated or some large chunk of bad data is being accessed.
> 
> ps. This comment applies to all the logs of this nature.

I'm a little hesitant to do this, only because the database is still relatively
new and hasn't been strained. I'd be curious how often it fails, and under what
circumstances, so we can fix it. With this more silent option, we only see it if
we look for it (and with how many VLOG(1)'s are in the source, we have to look
*hard*). I'd prefer to keep it as a LOG for now - if we have a lot of prints,
then we can change it (or better, fix it). Since we only run PM right now with
the flag, we can assume anyone running it will consent to a bit more output :)

https://chromiumcodereview.appspot.com/10907121/diff/2001/chrome/browser/perf...
File chrome/browser/performance_monitor/database_unittest.cc (right):

https://chromiumcodereview.appspot.com/10907121/diff/2001/chrome/browser/perf...
chrome/browser/performance_monitor/database_unittest.cc:68: 
On 2012/09/07 23:10:55, eaugusti wrote:
> nit: extra space

Done.

https://chromiumcodereview.appspot.com/10907121/diff/2001/chrome/browser/perf...
File chrome/browser/performance_monitor/metric.cc (right):

https://chromiumcodereview.appspot.com/10907121/diff/2001/chrome/browser/perf...
chrome/browser/performance_monitor/metric.cc:86: bool Metric::Validate() const {
On 2012/09/07 23:10:55, eaugusti wrote:
> Should this validate the type too?

Done (it'll already return false on Undefined metrics, but now it will return
false if it's METRIC_NUMBER_OF_METRICS, too).

[eaugusti, 2012-09-10 18:21:04]

lgtm

[Devlin, 2012-09-10 18:27:07]

+ Yoyo

[Yoyo Zhou, 2012-09-10 23:52:44]

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
File chrome/browser/performance_monitor/database.cc (right):

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/database.cc:164: if (!(value =
base::JSONReader::Read(it->value().ToString())) ||
Assignment inline inside conditionals isn't recommended for readability. Try a
helper function instead.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/database.cc:169: LOG(ERROR) << "Unable to
convert database event to JSON. Erasing the "
You should log something identifiable about the event; otherwise this message is
of very limited utility.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/database.cc:202: LOG(ERROR) << "Metric is not
valid; ignoring.";
Same here. What is the invalid metric?

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/database.cc:361: LOG(ERROR) << "Found bad
metric in database. Erasing the metric from "
Same comment, etc.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/database.cc:366:
results.push_back(Metric(metric_type,
This is already called 'metric'

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/database.cc:403: Metric(metric_type,
split_key.time, it->value().ToString()));
ditto

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
File chrome/browser/performance_monitor/database_unittest.cc (right):

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/database_unittest.cc:483: ASSERT_EQ(1u,
stats.size());
Should this 1u be the original_number_of_entries?

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
File chrome/browser/performance_monitor/metric.cc (right):

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/metric.cc:28: const double
kMaxSharedMemoryUsage = 1024.0 * 1024.0 * 1024.0 * 1024.0;  // 1 TB
Can you use the constants from the unit-conversion changelist?

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/metric.cc:30: const double kMaxStartupTime =
1000000 * 60 * 15;  // 15 minutes
Be consistent about using foo or foo.0.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/metric.cc:40: const double
kMaxNetworkBytesRead = static_cast<double>(kint64max);
This is kind of hackish. It'd be better to change the comparison in Validate so
that e.g. it passes if the max is 0 (but this is merely a better hack and still
must be documented).

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/metric.cc:47: const MetricBound
kMetricBounds[] = {
If we still had metric_details I would suggest that this goes there.  As it is,
having max/min information here is a little weird.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/metric.cc:88: value < kMetricBounds[type].max
&& value > kMetricBounds[type].min;
So 0 is going to be an invalid value for all of these metrics?

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
File chrome/browser/performance_monitor/metric.h (right):

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/metric.h:46: bool Validate() const;
This should be called something like IsValid.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/metric.h:48: std::string ValueAsString()
const;
Does this make sense if the metric isn't valid? If not, document it as such.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
File chrome/browser/performance_monitor/performance_monitor.h (right):

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/performance_monitor.h:135: // construct a new
metric on the background thread.
I'm not sure this does what you think. You are still constructing Metric where
you post the callback, and then making a copy of it, if I understand correctly.

[Devlin, 2012-09-11 18:52:17]

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
File chrome/browser/performance_monitor/database.cc (right):

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/database.cc:164: if (!(value =
base::JSONReader::Read(it->value().ToString())) ||
On 2012/09/10 23:52:44, Yoyo Zhou wrote:
> Assignment inline inside conditionals isn't recommended for readability. Try a
> helper function instead.

Done.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/database.cc:169: LOG(ERROR) << "Unable to
convert database event to JSON. Erasing the "
On 2012/09/10 23:52:44, Yoyo Zhou wrote:
> You should log something identifiable about the event; otherwise this message
is
> of very limited utility.

Done.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/database.cc:202: LOG(ERROR) << "Metric is not
valid; ignoring.";
On 2012/09/10 23:52:44, Yoyo Zhou wrote:
> Same here. What is the invalid metric?

Done.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/database.cc:361: LOG(ERROR) << "Found bad
metric in database. Erasing the metric from "
On 2012/09/10 23:52:44, Yoyo Zhou wrote:
> Same comment, etc.

Done.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/database.cc:366:
results.push_back(Metric(metric_type,
On 2012/09/10 23:52:44, Yoyo Zhou wrote:
> This is already called 'metric'

Done.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/database.cc:403: Metric(metric_type,
split_key.time, it->value().ToString()));
On 2012/09/10 23:52:44, Yoyo Zhou wrote:
> ditto

Done.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
File chrome/browser/performance_monitor/database_unittest.cc (right):

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/database_unittest.cc:483: ASSERT_EQ(1u,
stats.size());
On 2012/09/10 23:52:44, Yoyo Zhou wrote:
> Should this 1u be the original_number_of_entries?

Done.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
File chrome/browser/performance_monitor/metric.cc (right):

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/metric.cc:28: const double
kMaxSharedMemoryUsage = 1024.0 * 1024.0 * 1024.0 * 1024.0;  // 1 TB
On 2012/09/10 23:52:44, Yoyo Zhou wrote:
> Can you use the constants from the unit-conversion changelist?

Done. Moved the constants from the ui file to c/b/p_m/constants file, so that we
still only include in one direction (i.e., ui includes c/b/p_m, but not vice
versa). 

Is the unit conversion (or at least, the set of unit constants) something that
we should think about putting at a higher level (perhaps in base)? I know there
are other places in the codebase where some of these values are used, but it's
impractical to include a dozen different files for a dozen different
constants...

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/metric.cc:30: const double kMaxStartupTime =
1000000 * 60 * 15;  // 15 minutes
On 2012/09/10 23:52:44, Yoyo Zhou wrote:
> Be consistent about using foo or foo.0.

Done.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/metric.cc:40: const double
kMaxNetworkBytesRead = static_cast<double>(kint64max);
On 2012/09/10 23:52:44, Yoyo Zhou wrote:
> This is kind of hackish. It'd be better to change the comparison in Validate
so
> that e.g. it passes if the max is 0 (but this is merely a better hack and
still
> must be documented).

Done.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/metric.cc:47: const MetricBound
kMetricBounds[] = {
On 2012/09/10 23:52:44, Yoyo Zhou wrote:
> If we still had metric_details I would suggest that this goes there.  As it
is,
> having max/min information here is a little weird.

I'm not sure I agree that this is weird. It seems to me that since this is used
by the metrics and is directly related to them (and is only used for this
function), that this is the logical place for it. However, if you think this
would go better somewhere else (perhaps as a function, ValidateMetric(), in
performance_monitor_util?), I would be happy to do so :)

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/metric.cc:88: value < kMetricBounds[type].max
&& value > kMetricBounds[type].min;
On 2012/09/10 23:52:44, Yoyo Zhou wrote:
> So 0 is going to be an invalid value for all of these metrics?

It's difficult to say for sure. The only time I think we could really have 0 for
one of the (current) metrics is if we had a really powerful 1-cpu machine that
had chrome idling, and it was close enough to 0 to be reported as such. Changed
it to be safe, though.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
File chrome/browser/performance_monitor/metric.h (right):

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/metric.h:46: bool Validate() const;
On 2012/09/10 23:52:44, Yoyo Zhou wrote:
> This should be called something like IsValid.

Done.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/metric.h:48: std::string ValueAsString()
const;
On 2012/09/10 23:52:44, Yoyo Zhou wrote:
> Does this make sense if the metric isn't valid? If not, document it as such.

Done.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
File chrome/browser/performance_monitor/performance_monitor.h (right):

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/performance_monitor.h:135: // construct a new
metric on the background thread.
On 2012/09/10 23:52:44, Yoyo Zhou wrote:
> I'm not sure this does what you think. You are still constructing Metric where
> you post the callback, and then making a copy of it, if I understand
correctly.

I was modeling this after the io_data one. In that, Battre recommended I pass in
a copy, rather than a const ref, so that it would be thread-safe (see here:
https://chromiumcodereview.appspot.com/10829342/diff2/9003:10007/chrome/brows...
). I think that a const& would be safe here so long as we always construct the
Metric in the call (and the callback owns it), but would it still be safe if we
did:

Metric metric(...);
base::Bind(..., metric)

or would PerformanceMonitor's thread still own it?

[Yoyo Zhou, 2012-09-13 00:09:20]

LGTM

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
File chrome/browser/performance_monitor/metric.cc (right):

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/metric.cc:28: const double
kMaxSharedMemoryUsage = 1024.0 * 1024.0 * 1024.0 * 1024.0;  // 1 TB
On 2012/09/11 18:52:17, D Cronin wrote:
> On 2012/09/10 23:52:44, Yoyo Zhou wrote:
> > Can you use the constants from the unit-conversion changelist?
> 
> Done. Moved the constants from the ui file to c/b/p_m/constants file, so that
we
> still only include in one direction (i.e., ui includes c/b/p_m, but not vice
> versa). 
> 
> Is the unit conversion (or at least, the set of unit constants) something that
> we should think about putting at a higher level (perhaps in base)? I know
there
> are other places in the codebase where some of these values are used, but it's
> impractical to include a dozen different files for a dozen different
> constants...

If there's demand for it.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/metric.cc:47: const MetricBound
kMetricBounds[] = {
On 2012/09/11 18:52:17, D Cronin wrote:
> On 2012/09/10 23:52:44, Yoyo Zhou wrote:
> > If we still had metric_details I would suggest that this goes there.  As it
> is,
> > having max/min information here is a little weird.
> 
> I'm not sure I agree that this is weird. It seems to me that since this is
used
> by the metrics and is directly related to them (and is only used for this
> function), that this is the logical place for it. However, if you think this
> would go better somewhere else (perhaps as a function, ValidateMetric(), in
> performance_monitor_util?), I would be happy to do so :)

Oops, I think I had a half-formed thought there. Feel free to ignore it.

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
File chrome/browser/performance_monitor/metric.h (right):

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/metric.h:48: std::string ValueAsString()
const;
On 2012/09/11 18:52:17, D Cronin wrote:
> On 2012/09/10 23:52:44, Yoyo Zhou wrote:
> > Does this make sense if the metric isn't valid? If not, document it as such.
> 
> Done.

I was hoping more for something like, "This only makes sense if IsValid."

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
File chrome/browser/performance_monitor/performance_monitor.h (right):

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/performance_monitor.h:135: // construct a new
metric on the background thread.
On 2012/09/11 18:52:17, D Cronin wrote:
> On 2012/09/10 23:52:44, Yoyo Zhou wrote:
> > I'm not sure this does what you think. You are still constructing Metric
where
> > you post the callback, and then making a copy of it, if I understand
> correctly.
> 
> I was modeling this after the io_data one. In that, Battre recommended I pass
in
> a copy, rather than a const ref, so that it would be thread-safe (see here:
>
https://chromiumcodereview.appspot.com/10829342/diff2/9003:10007/chrome/brows...
> ). I think that a const& would be safe here so long as we always construct the
> Metric in the call (and the callback owns it), but would it still be safe if
we
> did:
> 
> Metric metric(...);
> base::Bind(..., metric)
> 
> or would PerformanceMonitor's thread still own it?

On reviewing the documentation in callback.h, this looks correct. Sorry for the
confusion.

https://chromiumcodereview.appspot.com/10907121/diff/13001/chrome/browser/per...
File chrome/browser/performance_monitor/database.cc (right):

https://chromiumcodereview.appspot.com/10907121/diff/13001/chrome/browser/per...
chrome/browser/performance_monitor/database.cc:175: LOG(ERROR) << "Found invalid
event in the database. JSON: '" <<
nit: put the << on the next line and align with <<

[Devlin, 2012-09-13 17:00:24]

+ Evan for (relatively small) webui changes

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
File chrome/browser/performance_monitor/metric.h (right):

https://chromiumcodereview.appspot.com/10907121/diff/10001/chrome/browser/per...
chrome/browser/performance_monitor/metric.h:48: std::string ValueAsString()
const;
On 2012/09/13 00:09:20, Yoyo Zhou wrote:
> On 2012/09/11 18:52:17, D Cronin wrote:
> > On 2012/09/10 23:52:44, Yoyo Zhou wrote:
> > > Does this make sense if the metric isn't valid? If not, document it as
such.
> > 
> > Done.
> 
> I was hoping more for something like, "This only makes sense if IsValid."

Done.

https://chromiumcodereview.appspot.com/10907121/diff/13001/chrome/browser/per...
File chrome/browser/performance_monitor/database.cc (right):

https://chromiumcodereview.appspot.com/10907121/diff/13001/chrome/browser/per...
chrome/browser/performance_monitor/database.cc:175: LOG(ERROR) << "Found invalid
event in the database. JSON: '" <<
On 2012/09/13 00:09:20, Yoyo Zhou wrote:
> nit: put the << on the next line and align with <<

Done.

[Evan Stade, 2012-09-14 08:39:16]

lgtm with nits

https://chromiumcodereview.appspot.com/10907121/diff/14003/chrome/browser/per...
File chrome/browser/performance_monitor/constants.h (right):

https://chromiumcodereview.appspot.com/10907121/diff/14003/chrome/browser/per...
chrome/browser/performance_monitor/constants.h:28: const int64 kBytesPerKilobyte
= 1 << 10;
define in cc

https://chromiumcodereview.appspot.com/10907121/diff/14003/chrome/browser/ui/...
File
chrome/browser/ui/webui/performance_monitor/performance_monitor_ui_constants.h
(right):

https://chromiumcodereview.appspot.com/10907121/diff/14003/chrome/browser/ui/...
chrome/browser/ui/webui/performance_monitor/performance_monitor_ui_constants.h:9:
#include "base/time.h"
remove

[Devlin, 2012-09-17 16:35:59]

https://chromiumcodereview.appspot.com/10907121/diff/14003/chrome/browser/per...
File chrome/browser/performance_monitor/constants.h (right):

https://chromiumcodereview.appspot.com/10907121/diff/14003/chrome/browser/per...
chrome/browser/performance_monitor/constants.h:28: const int64 kBytesPerKilobyte
= 1 << 10;
On 2012/09/14 08:39:16, Evan Stade wrote:
> define in cc

Done.

https://chromiumcodereview.appspot.com/10907121/diff/14003/chrome/browser/ui/...
File
chrome/browser/ui/webui/performance_monitor/performance_monitor_ui_constants.h
(right):

https://chromiumcodereview.appspot.com/10907121/diff/14003/chrome/browser/ui/...
chrome/browser/ui/webui/performance_monitor/performance_monitor_ui_constants.h:9:
#include "base/time.h"
On 2012/09/14 08:39:16, Evan Stade wrote:
> remove

Done.

[commit-bot: I haz the power, 2012-09-17 16:36:20]

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

[commit-bot: I haz the power, 2012-09-17 19:34:47]

Change committed as 157168