[UMA] Expand the comment for UMA_HISTOGRAM_SPARSE_SLOWLY

base/metrics/histogram_macros.h

Index: base/metrics/histogram_macros.h
diff --git a/base/metrics/histogram_macros.h b/base/metrics/histogram_macros.h
index d39972a8a12abde3b9a3159fe76c76f456de5580..7464cb722495a8d65b19f9092da3ced3f6194e3c 100644
--- a/base/metrics/histogram_macros.h
+++ b/base/metrics/histogram_macros.h
@@ -247,7 +247,12 @@
 //
 // UMA_HISTOGRAM_SPARSE_SLOWLY is good for sparsely distributed and/or
 // infrequently recorded values since the implementation is slower
-// and takes more memory.
+// and takes more memory. For sparse data, sparse histograms have the advantage
+// of using less memory client-side, because they allocate buckets on demand
+// rather than preallocating. However, server-side, we still need to load all
+// buckets, across all users, at once. Thus, please avoid exploding such
+// histograms, i.e. uploading many many distinct values to the server (across

[jkrcal, 2017/04/19 07:58:06]

Maybe we can make the "many many" more concrete. Roughly how many is "many many"
in this context?

[Ilya Sherman, 2017/04/19 17:22:07]

<= 100 is best, and <= 1000 is okay (but more expensive, and overkill in many
cases).

[jkrcal, 2017/04/26 07:39:14]

Done.

+// all users).
 //
 // For instance, Sqlite.Version.* are sparse because for any given database,
 // there's going to be exactly one version logged.