Re: [pygame] pygame slowness

[Randy Kaelber <randy@xxxxxxxxxxxx>]

On Thu, Dec 15, 2005 at 09:04:10PM +0100, Lionel barret De Nazaris wrote:

> <rant on>
> By the way, I looked at the source code of many pygame games, I felt 
> they were they were not very structured.
> I mean no offense (after all these games run far better than mine), but 
> I am afraid that my style may be too structured (or too abstract) for 
> python.
> I know that "flat is better than nested" but I think that "simple is 
> better than complicated", and to make things simple, you  need to create 
> abstractions.
> In a game  that could mean many abstractions.
> <rant off>
> 
> Sorry, for the rant, it has been a very long day.

There's no need to apologize at all!  This is one of the standard software 
engineering tradeoffs.  We are lucky to live in a world where we can 
execute a few thousand extra instructions to do a task and noone generally 
notices, so we can use many layers of abstractions to save programmer's 
brainpower to actually solve problems.  Unfortunately, for some things 
(operating systems and games being two notable domains) efficiency still 
rules.  

The Linux kernel has some strange, arcane and crufty-looking code in it, 
but it's not because the kernel developers are bad engineers.  There's 
performance hacks like getting a packet of data directly from the 
filesystem and sticking it in a network packet that would make OO 
adherents openly weep in their Gang of Four books, but are done 
specifically to improve a critical part of system performance.

Still, premature optimization can kill a project before it gets going.  
As I stated before, unless the performance is so bad you can't even 
effectively test your program, I'd hold off optimizing until you're nearly 
done.  15 fps may be unplayable for a finished product, but I think that 
you can generally test decently with that frame rate.  I'd keep on 
writing, and then when you've got your functionality in place, start 
unwinding the things that are killing your performance.

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