On Wed, Sep 19, 2012 at 05:47:15PM -0400, Ehsan Akhgari wrote: > 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.
We could, however, instrument there. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
