CD Actual 15/CDACTUAL15.iso/cdactual/program/pascal/PROFILER.ZIP/PROFILE.DOC

Text File | 1987-01-02 | 8.8 KB | 177 lines

       EXECUTION PROFILER    --by Ralph G. Brickner

     Taken from PC Tech Journal, Nov/86 by Geoff Mitchell, Big Blue & Cousins
     Document by Geoff Mitchell

This is a rather nice profiler and since the full source code is included
you can customize it.  If you want a full explanation of all the ins and outs,
you should get a copy of the article.

If you should get the magazine, you will find a few changes in the assembly
language coding.  This is because the version in the magazine generated phase
errors when I assembled it with MASM 3.0.  Brickner used the IBM Macro assembler
version 1.0 which may account for the difference.  In any case, I found it
necessary to re-arrange the subroutines.

TURBO version 3.0 was the Pascal compiler used.  The Pascal source is
unchanged except to place the statement  LowVideo; in the first display
procedure.

The package consists of the following files:

PROFILE.BAT
PRF.COM
LISTPRF.COM
PRF.ASM
LISTPRF.PAS


There are a few items which you need to know in order to operate the program
without the magazine as a reference.

1.  The first three files above must be in your default directory as well
     as the program you wish to profile.

2.  There must be enough room left over in that directory (or that disk
    drive) for the program you wish to profile to be copied.

    If you look at PROFILE.BAT, you will see that the first thing it does
    is copy your test program into a file called SUBJECT.COM.  It does not
    matter if your program has an .EXE extension.  SUBJECT.COM is then run
    from within PRF.COM and deleted by PROFILE.BAT when it is finished.

3.  A further examination of PROFILE.BAT indicates that you can pass up to
    two paramters for your test program.  For instance, if you wish to
    profile the DOS program COMP.COM and have it work on the files TEST1.TXT
    in Drive B and TEST2.TXT in Drive C, then put COMP.COM and the three
    profiler files in Drive A and enter the command:

    A> PROFILE COMP.COM B:TEST1.TXT C:TEST2.TXT

    since the echo is on, you can watch the progress of events.  You will not
    be able to profile a program with three or more parameters.

4.  The profiler consists of two parts:

        A. PRF.COM is the actual profiler, what Brickner calls the kernel.

        PRF.COM loads and executes the program to be profiled.  While that
    program is running, it uses the timer interrupt to gather the locations
    your code spends its time and store them in memory. It does this by
    copying into a RAM buffer the contents of the CS and IP registers from the
    stack where they are pushed by INT 8 (the timer interrupt) which in a
    normal PC is invoked 18.2 times per second .

        The buffer set aside in memory to store this information is 60K. A
    little arithmetic should prove that you can store 15,000 double words (the
    space required by CS:IP) in 60K which at 18.2 samples per second should
    take 844 seconds. This is the limit of PRF.COM in its default
    configuration.

        You can change these default settings, however.

        The constant TABLE_SIZE is the first equate in PRF.ASM and can be
     changed from 0F00H (60K) to whatever memory you think you can afford.

        The constant NUMBER_OF_TICKS is the second equate.  It is set at 1.
     For small programs, you can increase this which has the effect of
     speeding up the clock so you take more samples per second.  As you speed
     up the system clock, there is some degradation of performance of the
     program you are executing as more and more processer time is spent
     running the profiler.

        If you mulitply the sampling rate ten times by equating
     NUMBER_OF_TICKS to 10, then you would be able to run a program for
     approximately 844/10 seconds before filling your data buffer.  The
     relation is only approximate due to the time overhead of running the
     profiler.

        If you speed up the sampling by a factor of 500, time is split more or
     less evenly between the profiler and the program it is running.

        You should bear in mind that many operations of the disk controllers are
     timing loop dependent, so changing the clock rate can have unpredictable
     results in some applications.

        Changing these equates requires assembling, linking and converting to
     binary PRF.ASM.  If you should go through the hassle, it might be worth
     your while to have one version with the clock sped up 10 times, another
     50 times, and another 100 times in addition to the one you have received
     in which the clock is not sped up at all.

        If you wish to slow the sampling down for truly long-running programs,
     it should be fairly easy to change the sampling routine to take a
     sample on every other clock tick, or every tenth one, or what have you.

        B. LISTPRF.COM

        This program simply displays the information gathered by PRF.COM.
     The coding is a little tricky in places and it does have a few bugs when
     you start pushing it to its limits.  TurboPascal programmers might like
     to play around with it a bit and do some fixups.

        The first screen is pretty well self-explanatory.  If you should have
     changed the clock rate, however, you will find that the elapsed time
     displayed will have been increased by the factor of the speed-up.  Among
     other things, this screen displays all the code segments accessed by the
     tested program with the number of samples in each.  These segments are
     numbered from one up.  You should note the numbers of the ones you are
     interested in because once you leave this screen, you cannot get back to
     it and access the information contained therein.  Another fix perhaps?

        The next screen displays a histogram of the information contained in
     the first screen.  It is labelled Segment Histogram.  If you answer 'y'
     to the print prompt, it will dump it to your printer as well.

        You are then prompted for a particular segment.  After inputting a
     segment number, you are prompted for 'number of bins desired (< = 2048)'.
     This is where things get interesting.  What the program does is subtract
     the minimum offset from maximum offset of your code in that segment and
     divides the result by the 'number of bins' you input in order to
     create a sampling interval.  It then prints out a histogram of the number
     of hits in each bin.  It also gives you the opportunity to forgo
     displaying empty bins.

        Each line of the histogram starts with an offset into the specified
     segment followed by some figure which is the width in bytes of the bins
     as you specify them.  The program loops so you can go through the
     procedure several times specifying different numbers of bins which  has
     the effect of varying the distance from which you see the data.

        By increasing the number of bins, you reduce their width and so space
     the hits out.  In many programs, it should be possible to track the
     execution of particular instructions down to their exact addresses.
                      ------------------------

                      General Comments.

         The main problem with this program is that the sampling cannot be
turned on or off.  You have to sample an entire program, not just the
particular part in which you happen to be interested.

        A means does exist to change this.  PRF.ASM checks a flag (ACCUM_FLAG)
to see if it should accumulate data or not.  To implement turning sampling on
and off, PRF.COM and SUBJECT.COM must agree on a location for the flag so that
SUBJECT may set it and PRF read it.  A relatively safe place to put it would
be in the area used by the BASIC interpreter at 0000:0128.  Using relative
addressing could create problems.

        Obviously, it is not possible to do this without access to the source
code of the program being profiled; but that should be no problem with
programs you are developing yourself.

        A second improvement would be to utilize DOS memory management
functions to eliminate the pre-initialized 60K memory buffer.  This should not
be too hard to do and would have the effect of cutting the size of PRF.COM
from 63K to 3K thereby saving alot of disk space and loading time.

        A third problem with this program is that it cannot be used to profile
resident programs.  It is difficult to see how that can be rectified.  If you
should try to profile a resident program, it will do a profile of the
installation O.K. but as soon as the DOS terminate and stay resident function
is called, control will be handed back to PRF.COM and the profiler will go
into its display phase.