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.
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.