ORCA/C : The Profile Command

One of the advanced features of the debugger that can help
you improve a program is the profiler. The profiler collects
statistics about your program to help you find bugs and "hot
spots". A hot spot is a place in your program that takes a 
long time to execute compared with the rest of the program.
You may have heard of a famous rule of thumb in programming
which states that a program spends 90% of its time in 10% of
its code. The 10% of the code is the hot spot, and knowing
where it is can help you speed up your program.
	As you can see, the sort program you just opened has
two subroutines, named ShellSort and BubbleSort. Shrink the
window to about half its width. Pull down the Debug menu and
select the Profile command. This turns the profiler on. Next,
use the Compile to Memory command to compile and execute the
program, just as you did with the bull's eye program. After 
the program compiles and executes, you will see the profiler's
statistics printed in the shell window. The profiler returns
the following information :

1. The number of times each subroutine and main program was called
2. The number of heartbeats while in each subroutine and the main program.
3. The percent of heartbeats for each subroutine and main program
compared to the total number of heartbeats

	This information is in columns, and won't all be visible
unless you expand the size of the shell window. If you don't
see three columns of numbers after the names of the subroutines,
make the shell window larger.
	The number of times a subroutine is called is more useful
than it seems at first. For example, let's say you are testing
a program that reads characters from a file and processes them -
a spelling checker, perhaps. If you know that the test file has
3278 characters, but the subroutine you call to read a single
character is called 3289 times, you know right away that there
is a problem. In addition, if you are really calling a subroutine
3278 times, and the subroutine is a short one that is only called
from a few places, you might want to consider placing the few
lines of code "in-line", replacing the subroutine calls. 
Your program will get larger, and perhaps a little harder to read,
but the improvement in execution speed could make these
inconveniences worthwhile.
	The sort program only calls each sort one time, so the
first column of information isn't very useful in this example.
We also see, however, that the sort program spent about 32%
of its time in the BubbleSort subroutine, about 42% of its time
in the ShellSort routine, and about 26% of its time in the
main program. At least for this type of data, then, the bubble
sort is the better choice. You should be aware that the statistics
generated by the profiler are based on a random sampling. It can
be quite accurate for some types of programs, and very unreliable
for others. To get the best results, run a program several times,
and try to use input data that will cause it to execute for
several seconds to a few minutes. The larger the sample, the
better the results will be.