Proposal to remove the function timer code

54 views
Skip to first unread message

Ehsan Akhgari

unread,
Sep 19, 2012, 12:04:28 AM9/19/12
to dev-pl...@lists.mozilla.org, Vladimir Vukicevic, Taras Glek
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.

This dates back to the infancy of our profiling tools, and we have a
much better built-in profiler these days which is usable without needing
a build-time option. I don't even have the scripts I used to parse the
output and the crude UI I used to view the log around any more. I've
stopped building with --enable-functiontimer for a long time now, and I
won't be surprised if that flag would even break the builds these days.

So, I'd like to propose that we should remove all of that code. Is
anybody using function timers these days? (I'll take silence as
consent! :-)

Cheers,
Ehsan

L. David Baron

unread,
Sep 19, 2012, 1:01:01 AM9/19/12
to dev-pl...@lists.mozilla.org
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)?

Otherwise sounds fine to me (though there could be somebody using it
who wants it to stay).

-David

--
ğ„ž L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂

Taras Glek

unread,
Sep 19, 2012, 2:14:47 AM9/19/12
to Ehsan Akhgari, Vladimir Vukicevic, dev-pl...@lists.mozilla.org
On 9/19/2012 7:04 AM, 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.
>
> This dates back to the infancy of our profiling tools, and we have a
> much better built-in profiler these days which is usable without
> needing a build-time option. I don't even have the scripts I used to
> parse the output and the crude UI I used to view the log around any
> more. I've stopped building with --enable-functiontimer for a long
> time now, and I won't be surprised if that flag would even break the
> builds these days.
>
> So, I'd like to propose that we should remove all of that code. Is
> anybody using function timers these days? (I'll take silence as
> consent! :-)
You have my vote. I believe this code is still broken on Windows.
>
> Cheers,
> Ehsan

Ehsan Akhgari

unread,
Sep 19, 2012, 9:33:08 AM9/19/12
to L. David Baron, dev-pl...@lists.mozilla.org
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.

Cheers,
Ehsan

Vladimir Vukicevic

unread,
Sep 19, 2012, 1:07:40 PM9/19/12
to Ehsan Akhgari, Taras Glek, dev-pl...@lists.mozilla.org
On 9/19/2012 12:04 AM, 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.
>
> This dates back to the infancy of our profiling tools, and we have a
> much better built-in profiler these days which is usable without needing
> a build-time option. I don't even have the scripts I used to parse the
> output and the crude UI I used to view the log around any more. I've
> stopped building with --enable-functiontimer for a long time now, and I
> won't be surprised if that flag would even break the builds these days.
>
> So, I'd like to propose that we should remove all of that code. Is
> anybody using function timers these days? (I'll take silence as
> consent! :-)

Yep, sounds fine to me -- though we don't have equivalent functionality
right now, e.g. we don't quite have the ability to time/measure
"regions", if it's not being maintained it's not useful.

- Vlad


Zack Weinberg

unread,
Sep 19, 2012, 2:28:09 PM9/19/12
to
On 2012-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)?
>
> Otherwise sounds fine to me (though there could be somebody using it
> who wants it to stay).

I'd like to remind people of the existence of the JS performance timers
(js/src/perf). Appears never to have gotten an OSX or Windows back end,
but really ought to get used more than it does.

zw

Ehsan Akhgari

unread,
Sep 19, 2012, 2:40:03 PM9/19/12
to dev-pl...@lists.mozilla.org
I filed bug 792502 to kill FunctionTimer and friends.

Ehsan

Andrew McCreight

unread,
Sep 19, 2012, 2:49:26 PM9/19/12
to dev-pl...@lists.mozilla.org


----- Original Message -----
> Yep, sounds fine to me -- though we don't have equivalent
> functionality
> right now, e.g. we don't quite have the ability to time/measure
> "regions", if it's not being maintained it's not useful.

I actually ended up reimplementing something like this for the cycle collector (see COLLECT_TIME_DEBUG in nsCycleCollector.cpp) for fine-grained profiling of the cycle collector. I looked at the function timer code, but I didn't want to have to rebuild the entire browser just to enable it, so I ended up writing my own simple timing class.

Andrew

Ehsan Akhgari

unread,
Sep 19, 2012, 5:02:06 PM9/19/12
to Andrew McCreight, dev-pl...@lists.mozilla.org
Thanks for mentioning this!

Ehsan

Steve Fink

unread,
Sep 19, 2012, 5:08:40 PM9/19/12
to Ehsan Akhgari, L. David Baron, dev-pl...@lists.mozilla.org
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.

Ehsan Akhgari

unread,
Sep 19, 2012, 5:47:15 PM9/19/12
to Steve Fink, L. David Baron, dev-pl...@lists.mozilla.org
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

Mike Hommey

unread,
Sep 20, 2012, 1:54:37 AM9/20/12
to Ehsan Akhgari, Steve Fink, dev-pl...@lists.mozilla.org, L. David Baron
We could, however, instrument there.

Mike

Ehsan Akhgari

unread,
Sep 20, 2012, 8:26:06 PM9/20/12
to Mike Hommey, Steve Fink, dev-pl...@lists.mozilla.org, L. David Baron
On 12-09-20 1:54 AM, Mike Hommey wrote:
>> 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.

Do you have an idea on how that would work well with sampling?

Ehsan

Reply all
Reply to author
Forward
0 new messages