Trace stats in RTCStatsCollector.

webrtc/pc/rtcstatscollector.cc

Index: webrtc/pc/rtcstatscollector.cc
diff --git a/webrtc/pc/rtcstatscollector.cc b/webrtc/pc/rtcstatscollector.cc
index f5b8c8a936c1b569826ff20d98741e62ddb5e550..4aa7ecb48ef255b1d675be3217998dce0bbe2208 100644
--- a/webrtc/pc/rtcstatscollector.cc
+++ b/webrtc/pc/rtcstatscollector.cc
@@ -25,6 +25,7 @@
 #include "webrtc/pc/webrtcsession.h"
 #include "webrtc/rtc_base/checks.h"
 #include "webrtc/rtc_base/timeutils.h"
+#include "webrtc/rtc_base/trace_event.h"
 
 namespace webrtc {
 
@@ -751,6 +752,17 @@ void RTCStatsCollector::AddPartialResults_s(
     channel_name_pairs_.reset();
     track_media_info_map_.reset();
     track_to_id_.clear();
+    for (const RTCStats& stats : *cached_report_) {
+      for (const RTCStatsMemberInterface* member : stats.Members()) {
+        if (member->is_defined()) {
+          std::ostringstream trace_name;
+          trace_name << stats.type() << '.' << member->ValueToString();

[hbos, 2017/07/12 13:01:15]

If you place this in a helper function that is only invoked in the
TRACE_EVENT_INSTANT2 macro arguments then you don't end up creating all these
strings for naught if the trace is disabled.

That or #ifdef-ing the whole for-loop to match "if tracing enabled".

Speaking of which, how is it decided if this will be enabled or disabled?

[ehmaldonado_webrtc, 2017/07/12 13:23:30]

Done.
I don't know how it's decided, there are several layers of macros that I haven't
fully understood.

+          TRACE_EVENT_INSTANT2("webrtc_stats", trace_name.str().c_str(),
+                               "value", member->ValueToString(),
+                               "id", stats.id());

[hbos, 2017/07/12 13:01:15]

Does the order of "value" and "id" matter?

I just remembered, there's also stats.timestamp() which is when the stats object
was last updated. But there's no TRACE_EVENT_INSTANT3. If that is of interest
you could add a separate trace for the timestamp on a per |stats| basis.

[ehmaldonado_webrtc, 2017/07/12 13:23:30]

The order doesn't matter.
The timestamp is not of interest for now.

+        }
+      }
+    }
     DeliverCachedReport();
   }
 }