[Tutor] python, speed, game programming

spir denis.spir at gmail.com
Sat Jan 4 00:12:52 CET 2014


On 01/03/2014 10:53 PM, Keith Winston wrote:
> My concern is with speed. This will have to keep up with (somewhat
> arbitrarily) fast typing, while doing background processing, with a GUI of
> course.

I wouldn't even bother. Try & see, you may be surprised. There are several 
factors at play:
* The core processing in dealing with user input (read, decode, store, queue key 
strokes, etc) will be done by low-level (OS) routines written in C, with only 
thin Python wrappers (which essentially translate from/to python data types).
* Similar point for GUI and/or other user interface layer (less so if you'd use 
a pure python GUI framework, but in general they're also just wrappers over C code).
* The ratio between such low-level processing and actual processing code written 
and executed in python for your application logic is certainly high (as is 
usually the case), unless there is much realtime computation you did not speak 
about.
Anyway, just try and see.

This is similar to how & why python is reputed to be good (read: fast) at 
"number crunching": they are standard libs for that just link to low-level C 
routines which do about all computation, behind the stage, and very few 
application logic remains written *and actually executed* in python (search 
"numpy").

Denis


More information about the Tutor mailing list