efficiency of && vs. array

[Flash Gordon]

Chris Dollin said:


That's another way of saying the same thing.

Actually, please forgive me for saying so, Chris, but I think mine is more
generally useful.

I would have put something like this as rule 4 and for rule 3 have
something like:

3) See if you have a performance problem.

The point being that you can see if you have a problem generally rather
more easily than doing the measurements to find out where the
performance bottle neck is. Why go to that effort if you don't need to?

 

[Malcolm]

Rule 1: Don't do it.

Rule 2 (for experts only): Don't do it /yet/.

My candidate for Rule 3 would be: If you must do this damn silly thing,
don't do it in this damn silly way.

My rule would be: remove the giftwrapping if you don't want to give the code
to someone else.

Everyone says that you should try algorithmic optimisation first, which is
true as far as it goes. Often, however, the main reason prgorams run slower
than required is because they are reformatting and recalcuating data to make
it easy to pass to lower-level functions.

For instance I have model which is described by torsion angles along a set
of links. The obvious way to get it into Cartesian coordinates is to pass in
the angles, and do rotations. However the set of allowed angles is rather
small. Therefore I can speed it up by precalcuating sines and cosines, but
only at the price of tying my allowed angle set to the conversion routine.
As it happens, the discrete angle set is causing us all types of problems,
so I was able to rewrite the program in about two hours to use continous
angles, to see whether improvement in flexibility was worth it. It would
have been harder had the code not been gift-wrapped.