Add new UMA stats to get a handle on Downloads UI Usage

content/browser/download/download_stats.cc

Index: content/browser/download/download_stats.cc
diff --git a/content/browser/download/download_stats.cc b/content/browser/download/download_stats.cc
index 1abbc8c48fdd9ace389cf5524dd28889c9c45165..d6daf3c3b18d652dbe87b9bd46173fc92a186954 100644
--- a/content/browser/download/download_stats.cc
+++ b/content/browser/download/download_stats.cc
@@ -173,4 +173,56 @@ void RecordDownloadMimeType(const std::string& mime_type_string) {
                             DOWNLOAD_CONTENT_MAX);
 }
 
+void RecordOpen(const base::Time& end, bool first) {
+  if (!end.is_null()) {
+    UMA_HISTOGRAM_LONG_TIMES("Download.OpenTime", (base::Time::Now() - end));
+    if (first) {
+      UMA_HISTOGRAM_LONG_TIMES("Download.FirstOpenTime",
+                              (base::Time::Now() - end));
+    }
+  }
+}
+
+void RecordHistorySize(int size) {
+  UMA_HISTOGRAM_CUSTOM_COUNTS("Download.HistorySize",
+                              size,
+                              0/*min*/,
+                              (1 << 10)/*max*/,
+                              32/*num_buckets*/);
+}
+
+void RecordShelfClose(int size, int in_progress, bool autoclose) {
+  if (autoclose) {
+    UMA_HISTOGRAM_ENUMERATION("Download.ShelfSizeOnAutoClose",
+                              size,
+                              128);

[Randy Smith (Not in Mondays), 2011/10/09 23:40:17]

Hmmm.  Thinking about it, why 128?  There's a way in which anything above 10-12
is "many", as they can't all be displayed on the download shelf, so (I presume)
user's will tend not to have more than that many in progress at a time.  I could
image we'd want to know when that does happen (though I'll bet you it points to
an OS organizer :-}), but I'm not sure that we really gain from having a fine
granularity between, say, 20 and 128.  It probably doesn't matter--it's not a
lot of memory--but I'd like to be mindful about memory footprint anyway.

An ideal world would be the standard logarithmic histogram (fine detail at the
small end, coarse at the large) where we could guarantee that "fine" meant "each
count gets its own bucket until six or so".  But we might actually get that. 
Maybe try a standard histogram with a max of 128, and see what the bucketing
looks like at the low values and if you think that'll give you the information
you want?

Or just ignore this comment--it isn't something I feel strongly about at this
size.  But my guess is that we've got a lower return of valuable information
from memory footprint investment in these histograms.

[benjhayden, 2011/10/10 16:27:11]

16?

+    UMA_HISTOGRAM_ENUMERATION("Download.ShelfInProgressSizeOnAutoClose",
+                              in_progress,
+                              128);
+  } else {
+    UMA_HISTOGRAM_ENUMERATION("Download.ShelfSizeOnUserClose",
+                              size,
+                              128);
+    UMA_HISTOGRAM_ENUMERATION("Download.ShelfInProgressSizeOnUserClose",
+                              in_progress,
+                              128);
+  }
+}
+
+void RecordClearAllSize(int size) {
+  UMA_HISTOGRAM_CUSTOM_COUNTS("Download.ClearAllSize",
+                              size,
+                              0/*min*/,
+                              (1 << 10)/*max*/,
+                              32/*num_buckets*/);
+}
+
+void RecordOpensOutstanding(int size) {
+  UMA_HISTOGRAM_CUSTOM_COUNTS("Download.OpensOutstanding",
+                              size,
+                              0/*min*/,
+                              (1 << 10)/*max*/,
+                              32/*num_buckets*/);

[Randy Smith (Not in Mondays), 2011/10/09 23:40:17]

And hear I'd actually increase the number of buckets.  I think we're more
interested in variation in something like the 1-10 range, and above that we're
thinking either major batch processor or OS organizer, and it'll be a little
hard to judge based on this statistic.  And I'm not sure how fine granularity 32
buckets will give us at the low end.  But again, I don't feel strongly.

[benjhayden, 2011/10/10 16:27:11]

64?

+}
+
 }  // namespace download_stats