Re: Inline asm?

[Dennis Payne <dulsi@identicalsoftware.com>]

> > Remember
> >   2) Analize where the code is too slow before optimizing.
> > It sucks to optimize the wrong function.  I know.
> 
> Heh. I take it that this is the "art more than science" part?
> How does what determine where the code is too slow? Line-by-line analysis?

Hopefully you have written modular code that can be timed and tested
individually.  Then you run lots of iterations and see which functions
perform poorly.  With code that can't easily be tested independantly
(or perhaps even if it can) you can dummy out sections thus determining
if that is consuming the time.  And yes a lot of this is "art more
than science".  Still unless the change drastically changes the speed
you should find some way of measuring the change.

Example One: Asteroid-like game runs too slow on 286.  Time spent on
optimizing the sprite drawing code.  However if I had changed the sprites
to only draw a single pixel I would have found it running at the same
slow speed.

Example Two: Server consumes all available processor time even for small
number of clients.  (Not a game server but the same principle applies.)
Commenting out the database call and hard-coding the result, drops the
cpu usage which then grows nearly linearly with the number of clients.
My guess is that the database calls are performing so sort of busy wait.

Dennis Payne
dulsi@identicalsoftware.com