This would be analogous to call hooks in Spidermonkey.

What do you want to measure? Shaver wrote a while back an aggregate measure which models the delay between runnables which is a pretty good measure of snappiness (no large delays). Seems like you want something different for startup: do you just want to mark points at which you get back to the main event loop, or also know what *type* of runnable is running next? Is it ok to instrument this with dtrace, or do you want something which works on non-mac platforms?

The goal here was to know the type of runnable. I was thinking we could add a debug-only name getter to nsIRunnable or something, and then code to log it as desired. Or would we want this in non-debug builds too?

If you build with RTTI (which is fine for debug and release builds) you can get type_info(runnable)->name(), if you just need the C++ class for the runnable. If you need something more specific, such as the parameters for the runnable, I think we should consider separating the scriptable nsIRunnable from a C++-only Runnable class.

Taras, would that be good enough for you? Is there a way to detect at compile-time whether RTTI is enabled? Alternately, does type_info() compile if RTTI is disabled and just return null at runtime? Or does it not compile at all if RTTI is disabled?

I think it doesn't compile at all. We could certainly add a NS_RTTI_AVAILABLE define at compile time, since we already have the --enable-cpp-rtti configure flag.

(In reply to comment #4) > Taras, would that be good enough for you? I'll investigate this, sounds like a good start.

Taras asked me to mention a few things here... I started a bit of investigation into when we're firing timers in bug 530703, turns out we're doing a lot even when "idle". I was initially worried that it would be hard to know what the timer was firing for, though it was easy enough to identify most instances manually with gdb (breakpoint and a bit of stepping). A way to identify+log them by just setting a compile flag would be nice. I also separately looked at when we're reading prefs (not too bad, except for the code bug 482985 added). A long term concern about this (and the timers) was how to detect regressions in the future to prevent backsliding. A way to measure and identify these things so that they could be checked as part of some test would be useful. Comment 1 also reminds me that I did some dtrace scripts to do kick off some profiling when event processing starts taking too long, but I never got them working quite right due to some funkyness with OS X event processing.

Just for reference, chromium tasks (same as runnables) are always coupled with a 'location' object, created with a macro ('FROM_HERE', see http://www.google.com/codesearch/p?hl=en#h0RrPvyPu-c/base/tracked.h&q=FROM_HERE%20package:src.chromium.org&sa=N&cd=1&ct=rc&l=87). I'm not in love with that system but perhaps one of our auto-rewrite folks could make a patch that does something similar without too much effort.