Add queued_time_ms trace for events in message loop

base/tracking_info.h

Index: base/tracking_info.h
diff --git a/base/tracking_info.h b/base/tracking_info.h
index dacbcea1d2b9d83a4734b5c5b21216f4cac004f7..4be2c8a40f49aa884dba05a3b094ec9edf57a184 100644
--- a/base/tracking_info.h
+++ b/base/tracking_info.h
@@ -27,6 +27,16 @@ struct BASE_EXPORT TrackingInfo {
                base::TimeTicks delayed_run_time);
   ~TrackingInfo();
 
+  // To avoid conflating our stats with the delay duration in a PostDelayedTask,
+  // we identify such tasks, and replace their post_time with the time they
+  // were scheduled (requested?) to emerge from the delayed task queue. This
+  // means that queuing delay for such tasks will show how long they went
+  // unserviced, after they *could* be serviced.  This is the same stat as we
+  // have for non-delayed tasks, and we consistently call it queuing delay.
+  TimeTicks EffectiveTimePosted() const {

[jar (doing other things), 2013/07/09 16:50:53]

Both uses of the return value immediately convert to:

tracked_objects::TrackedTime

You probably should adjust the return value here, and simplify that code.

[Xianzhu, 2013/07/09 17:22:43]

Done.

I thought of consistency with the type of time_posted and delayed_run_time. It's
fine to use TrackedTime as it's only used for tracing/profiling.

+    return delayed_run_time.is_null() ? time_posted : delayed_run_time;
+  }
+
   // Record of location and thread that the task came from.
   tracked_objects::Births* birth_tally;