@(#)profiling howto 18 AUG 1997 Rob Thomas robt@cymru.com
How to profile your C code for best performance under Solaris 2.5.X
(This philosophy applies to all UNIX flavours) 

Often times, we dash through our C programming with nary a thought towards
best optimization or the most efficient algorithms.  This can (does!) lead
to poor code performance, and might even bring a host to its knees if the
code is piggish enough.  Here are some Good Karma development tips for all
Unix developers to use:

1. Use lint(1b)!  I know, I know, lint whines about everything.  Well,
   that's the role lint plays.  With lint, you can catch seemingly
   benign bugs such as unused variables.  Why is this important?  Keep
   in mind that the data section of your code is static.  This means
   that any global variables you have declared, whether you use them
   or not, must have space allocated to them from the get-go.  Why 
   waste space?

2. During your development, use profiling.  Profiling allows you to see
   just where your code spends the bulk of it's time.  Sure, debuggers
   such as dbx (or even truss, really) will show you this.  However, you
   can spend a LOT of time staring at a gdb session before you might
   realize what's going on.  Better to let the compiler do it for you.
   Profiling is relatively easy to do:
   A. Compile your app with the -p (for profiling) flag:
      pudge$ cc -p moo.c -o moo
   B. Execute your app:
      pudge$ ./moo
      Hello, world!
   C. You will now have a file called mon.out that prof(1) can analyze.
      Run prof:
      pudge$ prof moo
       %Time Seconds Cumsecs  #Calls   msec/call  Name
       100.0    0.10    0.10      11      9.1     _ioctl
         0.0    0.00    0.10       1      0.      main
         0.0    0.00    0.10       1      0.      _exithandle
         0.0    0.00    0.10       4      0.      atexit
         0.0    0.00    0.10       1      0.      _fprintf
         0.0    0.00    0.10       1      0.      _profil
         0.0    0.00    0.10       1      0.      _nss_initf_passwd
         0.0    0.00    0.10       1      0.      _getpwnam
         .
         .
         .

   Now you can analyze your code, regardless of size, for the most 
   frequently used system calls, routines, what-not.  Even better, you
   can now optimize your code in the areas that need it most!

3. gcc versus native compilers.  I'm not going to go into the religious
   wars surrounding this issue.  I just want to mention one fact:  When
   you optimize under most stock compilers, you strip out the line number
   information that is required for most debuggers.  However, under gcc,
   optimization does not remove these line numbers.  Thus, you can debug
   your optimized code!  This can be a handy trick if you want the most
   bang during your debugging sessions (or if you want to test the 
   effectiveness of optimization).

   On the whole, I use native compilers for system programming (e.g. re-
   writing /bin/su) and gcc for everything else.  Your mileage may vary.

Questions/comments/bugs: Robert Owen Thomas, robt@cymru.com

Rob Thomas, robt@cymru.com
http://www.enteract.com/~robt