On 12-09-19 5:08 PM, Steve Fink wrote:
On 09/19/2012 06:33 AM, Ehsan Akhgari wrote:
On 12-09-19 1:01 AM, L. David Baron wrote:
On Wednesday 2012-09-19 00:04 -0400, Ehsan Akhgari wrote:
A while ago (I think more than a couple of years ago now), Vlad
implemented FunctionTimer which is a facility to time how much each
function exactly takes to run. Then, I went ahead and instrumented
a whole bunch of code which was triggered throughout our startup
path to get a sense of what things are expensive there and what we
can do about that. That code is hidden behind the NS_FUNCTION_TIMER
build-time flag, turned on by passing --enable-functiontimer.
Is any of the instrumentation worth turning into instrumentation for
the new profiler (SAMPLE_LABEL_* macros)?
I can go through the list and file bugs if I find anything
particularly useful.
Otherwise sounds fine to me (though there could be somebody using it
who wants it to stay).
I just confirmed that at least, nsGlobalWindow.cpp will not build with
--enable-functiontimer, and the fact that nobody has complained about
that before is a strong indication that nobody is using this code.
I was still building with this relatively recently, though I haven't
actually used it in at least a year and it's possible all of those
builds were JS shell-only which wouldn't be affected. I had my own UI
that used the functiontimer output, but I never bothered landing it and
now that we have JS call information in the profiler, there's no reason
to make any attempt to keep it alive.
Yeah I don't think js shell builds would be affected. And let's use the
past tense to refer to FunctionTimer from now on! It is dead on
inbound. :-)
At a theoretical level, instrumentation like functiontimer enables
things that sampling cannot. For example, you can accurately count
memory allocated within the activation of a function call (or other
metrics like cache misses, branch mispredicts, context switches, etc.).
But the new profiler uses both sampling and instrumentation (the latter
via SAMPLE_LABEL_*? I don't know the details.) I suspect I'm not saying
anything that everyone doesn't already know.
The sample labels will not provide instrumenting profiling. What
happens is that the sample labels build up a stack, and every time that
we pause the target thread when taking a sample, we walk that pseudo
stack and record it. This is what we use on platforms that we cannot
currently unwind the C++ stack, including mobile/b2g and
aurora/beta/release (where we don't build with frame pointers), and
should be mostly thought of as a replacement or addition to the native
stack.
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
