533971 - Provide a way to measure nsIRunnable execution

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[(dormant account)]

This would be analogous to call hooks in Spidermonkey.

Comment 1

[Benjamin Smedberg]

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?

Comment 2

[Boris Zbarsky [:bzbarsky]]

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?

Comment 3

[Benjamin Smedberg]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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?

Comment 5

[Benjamin Smedberg]

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.

Comment 6

[(dormant account)]

(In reply to comment #4)
> Taras, would that be good enough for you?

I'll investigate this, sounds like a good start.

Comment 7

[Justin Dolske [:Dolske]]

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.

Comment 8

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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.

Comment 9

[Andrew McCreight [:mccr8]]

Most runnables do have names in non-release builds nowadays thanks to the labelling work that happened a while ago (nsINamed). If somebody has some concrete ideas for how to take advantage of that, a new bug is probably in order.