Re: Optimizing heatbugs in Obj-C

[Nick Collier]

I'd like to add my 2 cents about optimization in general. In nearly
every case, optimization should only be done after profiling. In a
project I was working on, I was sure a certain piece of code, part of a
persistance framework for some database work, was causing an obvious
slow-down. I spent a day or two optimizing the piece of code with no
observable speed increase. I then did what I should have in the
beginning and profiled. The problem was in an entirely different piece
of code. (Note that this was not algorithimical optimization (replacing
the algorithm), but rather replacing things such as Vectors with arrays
and so forth.) Nearly all the software design books I've read have a
similar story. 

I'd also like to advocate a notion of good-enough or fast-enough
performance. There is always the opportunity to optimize, but if you
don't need to, don't bother. I've found that heavily optimized code is
harder to understand and thus reuse as a solution to similar problems. 
There is also trade off between safety/ease-of-use and speed especially
in the case of collections such as Vectors and so forth vs. arrays.

All that said, it is important to understand the consequence of coding
in one way versus coding in another, and how to do optimization when it
is needed.

Just my 2 cents,

Nick

Jan Kreft wrote:
> 
> Paul,
> 
> On Mon, 10 Apr 2000, Paul E. Johnson wrote:
> 
> > I found a study of Marcus's fast code for Java Heatbugs to be very
> > instructive and if any of you have comparable tips about writing faster
> > models, I would be glad to hear them. I guess I've said that before
> 
> from my own experience, I would say that the model design and the
> algorithms used are paramount. My first version of BacSim took 3 days to
> compute what the current version does in 10 min.
> 
> What did I change? The main idea was to separate the two different
> processes in the model, diffusion and growth, on the basis of their
> different time-scale. That is, you decouple the two processes, keeping
> growth in a frozen state while simulating diffusion, and diffusion in a
> pseudo-steady state while simulating growth.
> 
> Then, you are free to choose the fastest algorithm known to simulate
> diffusion, and it makes a huge difference. Ironically, the faster process
> takes most of the time of the CPU. Actually, I didn't choose the fastest
> algorithm but the fastest that I felt I could fully understand. An expert
> in the field could use a sophisticated adaptive grid that would be fine
> only were the gradients are steep. I guess that would speed things up
> 10-fold or more.
> 
> In general, there is a trade-off between speed and memory-use. Fast
> algorithms typically use a lot of memory to solve a system of equations
> simultaneously while slow algorithms are iterative and hence require less
> memory. On modern machines, there's always enough memory.
> 
> Dunno whether that applies to your sort of models at all, but hope someone
> finds this useful.
> 
> Cheers, Jan.
> 
> Dr. Jan-Ulrich Kreft                    Phone  +44 (0)29 20875278
> Cardiff School of Biosciences           Fax    +44 (0)29 20874305
> Cardiff University                      E-mail address@hidden
> PO Box 915, Cardiff CF10 3TL, UK
> 
>                   ==================================
>    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.

-- 
Nick Collier
Social Science Research Computing
University of Chicago
http://repast.sourceforge.net

address@hidden

                  ==================================
   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.