Histogram the time we spend resampling images. We suspect this may be causing...

Histogram the time we spend resampling images. We suspect this may be causing
performance problems, so it would be nice to see what average users are seeing.

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

[jar (doing other things), 2009-05-19 23:47:39]

http://codereview.chromium.org/113604/diff/1/2
File skia/ext/image_operations.cc (right):

http://codereview.chromium.org/113604/diff/1/2#newcode301
Line 301: UMA_HISTOGRAM_TIMES("Other.ImageResampleMS", delta);
Two things:

"Other" is an especially garbaged up group.  I'd strongly suggest you use a
group like "Image" as a place where you can land other histograms in/around this
one.  You might then use a name like:

"Image.ResampleMS"

The size limits on the above histogram are best for really short times, as the
histhogram will max out at 10 seconds.  I'm guessing that on a bunch of
platforms you'll have longer times.  I'd suggest using:

UMA_HISTOGRAM_MEDIUM_TIMES

which will give you up to 3 minutes, across 50 buckets.  You'll get plenty of
resolution at the low end, but I think you'll get more comprehensive data this
way.

If you really feel strongly about getting higher resolution *and* still
supporting the tail, you can use 
UMA_HISTOGRAM_CLIPPED_TIMES(name, sample, min, max, bucket_count)
but you have to give all the arguments shown (i.e., you don't get off as easy as
with the basic macro you used).  I only tend to use that fancier version when
I'm doing an experiment, and I need very fine-grained data, and then I sometimes
go for 100 as the bucket count, and you'll want min around 10ms or less.

[brettw, 2009-05-20 16:33:39]

I uploaded a new version with the name you suggested.

I'm not worried about the time range. If we see a nontrivial number samples in
the 10s bucket then the question is answered.

[jar (doing other things), 2009-05-20 16:49:05]

LGTM