Python: performance, footprint, multi-threading, etc.

[Tim Browse]

Hi,

I've just started looking into Python as a possible scripting language
for a game we're developing.  The design of Python looks great, and the
simplicity, portability, and embeddability (is that a word?) of it are
what attracts me most.

However, while I'm happy to use it as a scripting language in my next
application (and it's very likely that I will), there are a few things I
need to find out about before I can use it in our game.  If any of you
can offer any insight, I'd be most grateful.  To put things in
perspective, I'm talking about a 'real' commerical game, which will use
real-time 3D graphics, and run on PCs, Macs, probably on consoles such
as Dreamcast, PSX2, and maybe even Linux/BeOS if we get the time.

Anway, here are my main areas of interest/concern wrt Python:

Performance

I haven't checked the performance of Python yet - I don't know if it
will be fast enough for our purposes.  This isn't a question about
Python speed etc.; I'm merely stating this now to pre-empt any "You
lamer! Python is too slow for games" responses :).

Memory Footprint

I'm using Python on Windows, and the Python DLL is 550k.  I realise
that's not huge for what Python does, but it is a sizeable amount of
memory for my purposes, especially as it doesn't include memory needed
to actually run Python scripts, etc.  What I'd like to know is, is it
necessary for it to be this big?  i.e. are there language
features/extensions that can be easily disabled which will reduce the
footprint of the system?  If I decide to ship scripts as bytecode files,
is it easy to remove the compiler from the distribution, leaving
something that only executes byte-code files (i.e. the interpreter)?

My questions are not meant as criticisms of Python's design - far from
it.  I'm just asking as these modifications are likely to be
time-consuming tasks, and if anyone can raise a flag and say "I'm
familiar with Python's source code, and you really don't want to be
trying to do that" then that's the kind of information I'm looking for.

In summary, how can I reduce the size of python15.dll?  (For instance, I
notice from a cursory examination that it has over 170k of uninitialised
data.)


Serialising Interpreter State

As I'm talking about a game, literally after every frame is rendered,
the player might decide that now is the time they want to save the
game.  Therefore I need to be able to serialise the state of the
interpreter at any point, so I can save the state of the scripting
engine into the save file, so it can be restored later, and the saved
game can be resumed.

Is this an easy thing to do?  Is it even possible with the current
version of Python?


Multi-Threading

One of the options we are considering to make scripting easier is that
each entity/object in our game will have its own thread of execution
(c.f. UnrealScript for game script junkies).  How well does Python
perform in general if there are lots of threads?  I'm talking about of
the order of 100 threads active at a time - but many of these may be in
an idling/blocking state.

For instance, I know that Windows 9X supports threads, and they work
fine if you use a few on your program, but when you start to use a lot
(50-100+) it gets a bit unimpressive.  I'm not implying that Python uses
Win32 threads - I assume it does its own scheduling - but would it
suffer from similar problems if I were to try running 100 threads at
once?  Is this level of multi-threading not encouraged?


Thanks in advance to anyone who can offer any information.

For the record, Python is the top of my list of off-the-shelf scripting
languages I'm considering using, so it's not that I think it's bad or
anything.  In fact, it's currently the only one on the list.  (The
alternative is to write our own, which is precisely tailored to our
needs, which would solve all these problems, but take more time).

Anyway, thanks for reading this.

Tim
-- 
Tim Browse                      
Tech Lead/Honesty Evangelist    "The evil void pointer strikes again,
hiding
The Digital Village              types from our friend, the compiler." 
timb at tdv.com                                  -- Dale Rogerson, "Inside
COM"