Splitting this off from bug 715380. Also, I'm not entirely sure what the desired effect is here. For something like: setTimeout(...) // assume each one is long enough to overlap subsequent ones setTimeout(...) setTimeout(...) setTimeout(...) What information do you want collected from that? The number of pending timeouts when we schedule a new one?
I know very little of this, so bz or khuey will have to help clarify. For every nsITimer execution that contains setTimeout handlers, we should record the number of those into a histogram.
If I understand the code correctly, nsGlobalWindow::RunTimeout is called once per XPCOM timeout firing. It may dispatch multiple nsTimeouts (though it's called with a single nsTimeout. The loops in that function will be of interest to you.
OK, so that wasn't so hard. Do note that this patch uses Telemetry::AutoCounter from bug 716657; I'll make sure they go in in the proper order.
Attachment #587332 - Flags: review?(bzbarsky)
Comment on attachment 587332 [details] [diff] [review] patch for timers fired per nsITimer r=me
Attachment #587332 - Flags: review?(bzbarsky) → review+
Comment on attachment 587332 [details] [diff] [review] patch for timers fired per nsITimer Should prefix this histogram as DOM_
Adding DOM_ prefix per Taras's suggestion. Carrying over r+.
Target Milestone: --- → mozilla12
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.