Timer library

[Russ Allbery]

Fabien Tassin <fta at sofaraway.org> writes:
> According to Alex Kiernan:

>> OK, that makes sense. I've given the library code the first n elements
>> (depending on what's in the enum) so that things like history routines
>> in the libary can be timed, you then start your application numbering
>> at n+1 and pass N to the TMRinit routine. Per-application strings get
>> passed into summarise & it has the library strings hard coded.

> it is possible to use nested timers ?
> It is the reason I've created the history timer... it is sometimes
> interesting to have reports of nested functions as a tree like the one
> I've shown as a sample of "stathist".

The current innd timer code will do nested timers, or at least I didn't
see any reason why it couldn't the last time I looked it over.  It was
just that innreport didn't understand how to summarize the output in a way
that made sense.

>> What's the best way to pass this stuff to you for committing? I'm
>> rapidly approaching the point where its hard to separate out the
>> different pieces...

> unified or contextual patches sent to inn-patches at isc.org are usually
> fine.  If you Cc inn-workers, be careful, Listar doesn't like non ASCII
> attachments.

Yup.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>