Mail Archives: djgpp/1999/10/21/16:45:56
Eli Zaretskii wrote:
>
> On Wed, 20 Oct 1999, Damian Yerrick wrote:
>
> > > Anyway, you should never try to optimize the code before you wrote it.
> > > Once you get the program working, if it runs too slow, profile it and see
> > > where it spends most of the time. More often than not, you will be
> > > surprised by what the profiler shows. Which means that optimizing early
> > > generally means you optimize in the wrong place.
> >
> > Any good HowTo pages on optimization?
>
> On the net, I don't know. A good book about optimizations is "Writing
> Efficient Programs" by Jon Bentley (Prentice-Hall, 1982). Some of the
> material there is obsolete, because compilers are so much better now
> in optimizing code; but the principles still hold.
>
> Anyway, the two most important rules of optimization are:
>
> Rule no.1: Don't do it.
> Rule no.2: Don't do it yet.
>
> In fact, *because* the compilers are so good in optimizing, I think
> you should generally consider optimizations later in the program
> development cycle, and only if there's a real problem in program
> performance.
Also, when you do have a performance problem, start by looking at your
algorithm. In my YAMD malloc debugger, I once had a linear search for
allocated blocks. This was very slow. I could have rewritten it in
hand-tuned assembly, but it still wouldn't have helped very much.
Instead, I switched to a hash table. The search code went from taking
about 80% of the time to about 1%.
--
Nate Eldredge
neldredge AT hmc DOT edu
- Raw text -