optimization and C arrays (was Re: Return pointer to array: not possible?)

[Theodore C. Belding]

To echo what Marcus said, C pointers are nasty, nasty, nasty, and
bug-prone. Don't use them if you don't have to. Ideally, you should use
a container class that doesn't make you use naked C pointers, and that
checks for things like accessing elements of the container that don't
exist, going outside of the container's boundaries, etc.

As far as optimizing for speed goes, you should never, ever try to change
your program to make it faster without profiling it first to see where the
speed bottlenecks are. Read the gprof man page. To profile, you have to
compile your program with -pg. (I haven't used gprof specifically with Obj
C, myself, but I've heard it works.) In general, you can assume that 90%
of a program's run time is spent in just 10% of the code [1].  If you
don't profile, you're likely to optimize the wrong 10% of your program.

There's a couple rules  of thumb that you can generally go by, even 
without profiling:

1) Use the right algorithms and data structures for your problem. (If
you're worried that a Swarm list container is too slow for millions of
objects, maybe you should be using a binary tree or hash container
instead, not a C array.)
2) Avoid unnecessary creation and deletion of objects, or allocation or
deallocation of memory. Also avoid copying objects unnecessarily. 
3) Avoid calling unnecessary operating system routines and using
unnecessary I/O (especially disk I/O). Memory is much faster than disk, if
you can afford it, and every time you call an operating system routine
under Unix (including I/O routines), you take a huge performance hit.
Networks are even slower than disks.

But even these may not be your real bottlenecks, and you won't know unless
you profile your code. If you do figure out where your bottlenecks are,
there are many advanced techniques you can use, such as inlining, loop
unrolling, caching or lazy evaluation (if you *really* need them).

Don't worry too much about making your program run fast until you
make it run and run correctly.

Hope that helps.
-Ted

[1] Hennessy, John L., and David A. Patterson. (1996). Computer
Architecture: A Quantitative Approach. 2nd ed. Morgan Kaufmann. pp. 38-39.

--
Ted Belding                               address@hidden 
University of Michigan Program for the Study of Complex Systems
Homepage: http://www-personal.umich.edu/~streak/
PGP key:  http://www-personal.umich.edu/~streak/pgp-key.html



                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.