Re: [pygame] pygame slowness

[Randy Kaelber <randy@xxxxxxxxxxxx>]

On Thu, Dec 15, 2005 at 05:48:35PM -0800, Knapp wrote:
> 
>    In  some  ways  I  disagree  with  Randy  Kaelber  statement about not
>    optimizing until the end. If it is just hacks for speed I agree but if
>    it is poor code implementation then I disagree.

I believe you're in vehement agreement with me.  :-) I believe in writing 
good, clear and maintainable correct code first, and then improving it for 
performance reasons second.  Worrying too much about efficiency and speed 
before you have code that actually does what you need it to is premature 
optimization.  Sometimes, of course, I don't live up to my own beliefs, 
but it's because I'm a weak and imperfect human being. :-)

It's been my experience that too often we make bad guesses ahead of time 
as to what actually needs to be optimized.  To that end, you're better off 
having a clear, maintainable code base that does what it ought to rather 
than having a brittle mess that performs wonderfully but scares you 
everytime you want to add a new feature.  Obviously, the ideal is to apply 
best engineering practises at every step, but it's easy for even the best 
engineers to sometimes not see the forest because all these darn trees 
keep getting in the way.

I'm not advocating "just drop in random or bubble sort now and if it's a 
problem do quicksort later" things.  If you know the cleanest, fastest way 
to implement something, then naturally that's the way to do it.  But when 
you're in the thick of something where the ultimate algorithm is unclear, 
I come down on the side of "make the code readable, well-documented and 
correct first, then go back and optimize only if it becomes a problem."

-- 
Randy Kaelber                                        randy@xxxxxxxxxxxx
Scientific Software Engineer  
Mars Space Flight Facility, Department of Geological Sciences
Arizona State University, Tempe, Arizona, USA