Profiling a serial program killer

#!/bin/bash
rm ants
gcc -pg antfarmgl.c sighandler.c afopengl.c listman.c files.c \
  -lglut -lGL -lGLU  -lm -lasound -ljpeg -lgpm -o ants
if [ -e ants ]
 then
 ./ants
echo "There are ants here!"
gprof -b ants gmon.out > results-file.txt
kprof -p gprof -f results-file.txt
else
echo "There are no ants here!"
fi

      The important thing to notice in "gcc" is the use of the "-gp" option which generates the profile code in "gmon.out" .

      I thought I would give this as an example of how to use gprof, gcc, and kprof to profile code for speed. I have used valgrind, ltrace, objdump, nm, strace, xtrace, mtrace, gdb, core analysis ( with ulimit -c 50000 ) ( or better ulimit -c unlimited ), and diagnostics incorporated in the code itself. I think that debugging and code analysis is an absolute necessity in any project. I discovered numerous little things that I did not know even existed. Documentation is another place that must be done right.

      Interpretation of the results is a whole separate issue. Years of computer experience have taught me how and where to look and how to interpret the relationships. One interesting thing that I discovered is duplicate calls due to many levels of include. It is difficult to know when things like this happen without the proper tools. So I have a call that calls a library that in turn duplicates a call to an associated function. I would never expect that to happen, but it does.

      I can bet that there is some really weird code running around in the Windows world. The reason I think that is because it grows in the dark under pressure and can never be checked. I have done commercial development and I know that I was not allowed to spend the time to do appropriate code testing and analysis, simply because it was extra cost. It can cost twice or even ten times as much to make gospel code. It is worth it to me, as I can easily find flaws in the code, because those thousands of little things that creep into a complex system have been removed proactively.

ADDED: A nice trick is this::

SIGQUIT       3       Core    Quit from keyboard
SIGILL        4       Core    Illegal Instruction
SIGABRT       6       Core    Abort signal from abort(3)
SIGFPE        8       Core    Floating point exception
SIGSEGV      11       Core    Invalid memory reference

After starting the program, do "ps -A" at another terminal and then "kill -SIGILL #PID". Where PID is replaced by the actual process ID (PID) from "ps -A" and SIGILL could be any of the above. This allows you to see where a program is at if it enters an infinite loop. In conjunction with the SIGSEGV handler, this allows me to punch out places where the code hangs out