Re: hi-res profiling

On Wed, 2002-10-02 at 18:54, Andres Kroonmaa wrote:

> > 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.
>
> Yes, agree. This is also historical. Initial version wanted to make
> it possible for user to insert probes anywhere in code with freetext
> names and without a need to update .h files. Now that enum's gives
> alot of performance benefit, this should be redone.

I disagree. Squid will be running in relocatable in most every OS, so
making the data static will not enabl direct memory access. The best it
will do is make the lookup DS+constant rather than
pointervalue+constant. These two ops should be pretty dang close in
performance, and the tick retrieving call may prevent them having any
impact anyway. Having a pointervalue lookup is good because then
essentially no code changes when you introduce thread support - it
simply becomes the value of the pthread_key. While that particular code
path will have slightly higher overhead, it shouldn't go into kernel
space, only into libc to retrieve the thread information block.
 
> There is also mention of compiletime define to enable/disable
> measuring of unaccounted probetime, disabling it would cause notable
> probe code reduction and that should also be enclosed in ifdefs. Its
> left there for now, because I've found knowing unaccounted time is
> very useful to detect existence of pieces of code that were considered
> to be no cpu hogs, but unexpectedly became such.

I think that is a very useful thing to keep in. The probe code is for
developers anyway, so minor overhead doesn't matter.

Rob