Re: profilers

On 5 Dec 1997, Waverly Edwards wrote:
>|Can anyone tell me where to find resources for making an execution profiler.
>|Books, Websites, source code and just about anything else is welcome.


"William A. Barath" <wi534@victoria.tc.ca> writes
>The most efficient way I can imagine to do it is this: compile into
>each function a small code fragment at the entry and exit points which
>read a global variable containing the seed of a high-resolution timer
>and add the difference between the two reads to a table entry for that
>function. Easy, little overhead, little bloat, and accurate even if
>the timer is only good for milliseconds (due to the averaging effect
>of repeated updates.) I've never done it, but it seems quite
>reasonable.


It is not quite that simple - execution of a function can be suspended
for a number of reasons, including awaiting a non-deterministic event,
such as a key-press, and hence the timer must be stopped and restarted
before and after calls to such functions. This is can be done
reasonably simply in languages such as C, where you can use the pre-
processor to remap standard library functions to your own standard
library shell, which stops the timer, calls the standard libary
function, and then re-starts the timer. You do have the problem of
knowing which function the standard library function was called from;
this will be simple when C9X compilers appear, using __func__, but
until then you will have to write you own C parser. As John has
commented, using the -p option on UNIX cc is easier and probably more
accurate. This counts the number of executions of each function
rather than timing each function and hence you do not encounter the
problems described above or any loading effects on
multi-user/multi-tasking operating systems (which is virtually
everything except MS-DOS).
------------------------
Barry Martin
bwm@bwmartin.demon.co.uk
--

Return to the comp.compilers page.
Search the comp.compilers archives again.