Add UMA histograms for WebAudio

third_party/WebKit/Source/modules/webaudio/OfflineAudioContext.cpp

Index: third_party/WebKit/Source/modules/webaudio/OfflineAudioContext.cpp
diff --git a/third_party/WebKit/Source/modules/webaudio/OfflineAudioContext.cpp b/third_party/WebKit/Source/modules/webaudio/OfflineAudioContext.cpp
index dc3afb966c3be24c02b0a5c034ddb0727f8a75d7..3edf3d77f2cfdd1270762b6d05180ddb6f60c6b8 100644
--- a/third_party/WebKit/Source/modules/webaudio/OfflineAudioContext.cpp
+++ b/third_party/WebKit/Source/modules/webaudio/OfflineAudioContext.cpp
@@ -35,6 +35,7 @@
 #include "modules/webaudio/OfflineAudioCompletionEvent.h"
 #include "modules/webaudio/OfflineAudioDestinationNode.h"
 
+#include "platform/Histogram.h"
 #include "platform/audio/AudioUtilities.h"
 
 namespace blink {
@@ -90,6 +91,17 @@ OfflineAudioContext* OfflineAudioContext::create(ExecutionContext* context, unsi
             + ")");
     }
 
+    DEFINE_STATIC_LOCAL(SparseHistogram, offlineContextChannelCountHistogram,

[Mark P, 2016/05/23 18:10:24]

SparseHistograms are slow because they acquire a lock each time you emit to
them.
Are you sure you want to use the type of histogram here?
I would think for most of these counts an appropriate COUNT or ENUMERATED
histogram would be better.
ditto with all your other histogram usages in other files in this changelist.

[Raymond Toy, 2016/05/23 20:36:03]

We don't expect many offline contexts, so speed isn't important. (Plus we're
thread-limited on the number of simultaneous contexts.)
Yes, after your initial comment (about adding units), I see there are lots of
other types that we should consider. 

[Mark P, 2016/05/23 21:30:24]

Yes, I would encourage you to use other types when it feels appropriate.  Even
if speed isn't an issue, one thing to keep in mind is that sparse histograms can
grow in memory unbounded if you keep emitting distinct values to them.

[Raymond Toy, 2016/05/23 23:12:00]

Unboundedness might be problem?  Not really sure, but I suspect the sample rates
are probably the typical audio hardware sample rates (44.1 kHz, 48 kHz, mostly
and maybe 192).  The possible rates allowed by WebAudio are 3000-192000 Hz.

[Mark P, 2016/06/03 19:52:36]

I'm still nervous about these being sparse histograms.
I can easily imagine a web page showing off fun features, say, do something like
for i = 0 to 10000 {
  create and play audio context of length i
}
or
// Listen how sample rates affect things
for i = 3k to 192k {
  create and play audio context with sample rate of length i
}
and the browser's memory will expand substantially (O(megabytes)), which will
not be released until a reboot.

Are you comfortable with this penalty when webaudio pages do strange things? 
(Or are you sure no one is going to do strange things.)

And if the length goes from, say, 0 to 10m instead, we're talking hundreds of
megabytes.

...

Actually, I just noticed you use sparse histograms in many places in this
changelist.  I'll emphasize again that such histograms keep every distinct value
emitted to in memory for as long as chrome is running.  Please audit these to
make sure the distinct values in each histogram is going to be from a small set.

+        ("WebAudio.OfflineAudioContext.ChannelCount"));
+    DEFINE_STATIC_LOCAL(SparseHistogram, offlineContextSampleRateHistogram,
+        ("WebAudio.OfflineAudioContext.SampleRate"));
+    DEFINE_STATIC_LOCAL(SparseHistogram, offlineContextLengthHistogram,
+        ("WebAudio.OfflineAudioContext.Length"));
+
+    offlineContextChannelCountHistogram.sample(numberOfChannels);
+    offlineContextSampleRateHistogram.sample(static_cast<int>(sampleRate));
+    offlineContextLengthHistogram.sample(clampTo(numberOfFrames, 0, std::numeric_limits<int>::max()));
+
     audioContext->suspendIfNeeded();
     return audioContext;
 }