Re: [pygame] pygame performance limits

[Bill Coderre <bcbc@xxxxxxx>]

On Nov 23, 2011, at 10:35 AM, Nick Arnoeyts wrote:
> Yeah, I'm probably worrying prematurely.
> I'm very easily influenced by FUD and there are a lot of messages floating around that Python (and Ruby) are too slow for making games.

Since I started programming thirty years ago, and probably for the thirty years before that, people have ALWAYS complained that "high level" languages are TOO SLOW and USE TOO MUCH MEMORY.

Note that the definition of "high level" has changed over the years, but suffice it to say, pretty much every single programming language has been subjected to this complaint, from Python to Lisp, even FORTRAN.

The exception to the rule: C, because it was originally designed to be a very thin layer on top of assembler. (C actually does add code, and slow down your program, to do "fancy" things like make array references work like you think they do.)

There's also this false economy -- if you write your code in fewer characters, it'll run faster -- which eventually led to the "obfuscated C" contest. This is entirely false -- unless your compiler is absolute crap, it will optimize your programs just the same, whether they are 10 lines or 1. 

Indeed, if you spend a lot of time reducing your code to the bare minimum, it is more likely you will write incorrect code. 

This is so prevalent that Kernighan and Plauger, who were some of the first people to work on Unix and C, wrote a book called "The Elements of Programming Style," where they repeatedly hammered the idea that "clever" code is a terrible idea. 

	======> Knuth later said, "Premature Optimization is the root of all evil." <======

To a certain extent, C++ also is not regarded as "big" or "slow," but that's ONLY IF you give up the "good stuff" that makes it powerful: you can still have object-oriented programming, but not certain powerful features of inheritance! So in reality, for most code, C++ is not much faster.

The simple fact is this: For most high-level languages, you sacrifice some percentage of your CPU and your memory space, and in return, YOU SHIP COMPLETE PROGRAMS SOONER. You can find and fix bugs SOONER, and add new features (because your users get to mess around and figure out what the REALLY want) SOONER.

Making user wait while you screw around with your "clever" optimizations, then deal with the bugs those introduced, is silly, especially because modern computers are, actually, THOUSANDS of times faster than those of even 10 years ago. And users don't care if your program takes 250 KB or 1MB, because you have have many times that amount of images and sounds.

Now, of course, when you have a super-high-level language, like PyGame, and it's running in an interpreted language like Python, you will run out of power much sooner than you would in a language like C, especially on a "phone" computer.

This, however, is no reason to stop using PyGame -- it's a reason to improve PyGame. Improvements require a lot of technical knowledge, skill, and effort, but they benefit MANY.