From: Garrett Mitchener <wgm2@duke.edu>
  To  : 
  Date: 08 Mar 1999 21:17:10 -0500

optimization

I worked with a group today and helped them cut their indexing time in
half by compiling with optimization.  When we grade these, if there is
a speed part, it would be nice if everyone's code compiled the same
way.  Here's how you add optimization:

* Finish writing and debugging and profiling your code as you normally
  would.

* Do common sense optimization.  For example, my group cut their time
  by a factor of three by switching from sorting an slist, which is
  hugely slow, to using a map, which does most things in logarithmic
  time.  (It would be even faster to use the not-quite-STL hash_map,
  but there are some complications associated with that.)

  Don't pass strings or containers by value (see the help page,
  design hints, ...).  

  Remember to delete anything you new, and to delete[] anything
  you new[].  Memory leaks can make a program spend way too much time
  swapping to disk because it just uses more and more memory.  One
  semester, I had to grade one that ran for hours because of a memory
  leak.

* Run it, perhaps using the "time" command to see how long it takes.

* Once it's completely done, change the compile flags so you compile
  with -O2, and without -g or -pg.  This means you can't debug or
  profile an optimize-compiled program.

* Also take out the -fPIC from everything EXCEPT for library code.
  You MUST have -fPIC to MAKE shared libraries, but it slows down the
  code and should not be used except in that one case.  You don't need
  -fPIC in your applications (sools, scoobi, etc.) to USE shared
  libraries.

* Get rid of all your .o, .so, and .a files and executables (do make
  clean or something like that).

* Compile again, run, and note any time differences.

Note that sometimes -O2 breaks otherwise okay code because of bugs in
GCC.  Sometimes it causes the infamous "internal compiler error."
That's why you must develop your program without it first.

	Good luck,
	-- Garrett :-)