🚀 go-pugleaf

> doug writes:
> 
> Msg-ID: <658@xdos.UUCP>
> Posted: 11 Feb 90 17:22:51 GMT
> 
> Org.  : Hunter Systems, Mountain View CA (Silicon Valley)
> Person: Doug Merritt
> 
> In article <1092@mindlink.UUCP> a464@mindlink.UUCP (Bruce Dawson) writes:
> >
> >     One way of speeding this up is to write your own WritePixel() routine.
> 
> To give some idea, I did this for Thad's FaceShower program. It originally
> used WritePixel for displaying 256x256 (approx.) pixels, and took about
> 45 seconds. Changing to direct writes dropped it to around 20 seconds.
> So if that's the approximate amount of time you want to save, then this
> might be the way to go. (Factor of two.)
> 
> But usually it's the algorithm that benefits most from optimization.
> Changing the inline dithering calculations to table lookups with layout
> optimized for the screen's bitplane layout dropped the time from 20
> seconds to around 1 second. (Factor of twenty.)
> 
> Member, Crusaders for a Better Tomorrow         Professional Wildeyed
> Visionary

     Be careful where you give the credit for the speedup.  Changing the
algorithm, in this particular case, saved nineteen seconds.  Changing the
WritePixel() routine saved twenty-five seconds.  The only reason that changing
the algorithm looked so much better was because when you optimized it, it was
the only major user of CPU time left.  If you'd changed the algorithm and then
changed WritePixel, you would have reported just under a factor of two
improvement for the algorithm, and a twenty-six times increase for WritePixel.

     In reality, the two changes should share the credit, and little more than
a factor of two improvement is possible without _both_ of them.

.Bruce.

     P.S.  I totally agree that the potential speed increases from a bood
algorithm (as opposed to rewriting in hand coded assembler or similar
techniques) are generally more important.  But sometimes both are necessary,
and an optimized WritePixel() routine is particularly easy and can speed things
up greatly.