Re: hi-res profiling

From: Henrik Nordstrom <hno@dont-contact.us>
Date: Wed, 2 Oct 2002 09:26:02 +0200

On Wednesday 02 October 2002 02.23, Robert Collins wrote:

> Can probes reenter?
> Ie. does the follow 'do the right thing'
> foo (int n)
> {
> PROF_START (foo);
> if (n)
> foo (--n):
> else
> {}
> PROF_STOP (foo);
> }

Bad example. Will 'do mostly the right thing' irregardless if probes
can be reentered or not as your tail is empty..

A more interesting example is

foo (int n)
{
  PROF_START (foo);
  if (n)
     foo (--n):
  // do some time consuming task
  PROF_STOP (foo);
}

but I am not sure we have many of these conditions..

From reading the source it seems nesting is not supported very well
within the same performance counter. If you do the readings will be
somewhat screwed up usually giving more time spent in the counter
than actual, counting the time from last start to each stop.

Extending it to support nesting would not be too hard, but involves
overhead so counters needing nesting should perhaps use other calls.
Knowing which sections need nesting is not too hard. For such
counters I propose measuring the time from first start to last stop.

Some suggestions for optimizations:

The timer name can be eleminated from the profiling calls and moved to
xprof_InitLib. It is static for each timer so there is no need of
sending and assigning it on each call..

Maybe consider making the start/stop functions inline, at least up to
the "nesting / concurrent timers" check. I assume there quite often
will be two or more concurrent timers running, one large scope
counter and several small scope counters..

Consider eleminating the initlib check on each call, and instead have
it called early from main. The amount of code (including
xprof_update) is fairly small so inlining should help I think.

As the set of timers is static, make the array statically allocated.
This saves some most of the addressing complexity when updating the
timers, allowing direct memory access instead of indirect via a
pointer + offset, especially noticeable in case of inlined start/stop
functions.

Regards
Henrik
Received on Wed Oct 02 2002 - 01:26:18 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:16:51 MST