Performance in embeded / extended python

[Emmanuel Astier]

On Wed, 4 Jul 2001 13:08:19 -0700, "John Roth"
<johnroth at ameritech.net> wrote:

>
>"Emmanuel Astier" <emmanuel.astier at winwise.fr> wrote in message
>news:3b431024.15341289 at news.iway.fr...
>> Hi,
>>
>>
>> I embedded and extended python for a game, and I was REALLY
>> disappointed by the performances I get...
>>
>> Every frame of my game ( should be 60 time by second ) I call my
>> Python logical part from my C game with :
>
>There's one thing that needs to be said right off - while there are
>many successful commercial games that use a scripting language to
>control the actual flow of the game, they don't, and I must repeat,
>they don't call the script every frame. As you've noticed, it's just
>too slow. It's the responsibility of the game engine (written in C
>or C++, with Assembler assists as needed for performance) to
>handle everything until, and only until, the engine needs a decision.

I don't agree : I worked on a successful commercial game, and I writed
the script for this game, and it was REALLLY light, and I run it every
frame.
The language was far more simple and stupid that Python, but it was
aimed for a PSone ( 33Mhz ! ).
I was hoping that aiming a real PC, I could use a language like
Python.
But I agree my older script didn't had to handle 200 objects per
seconds.

BTW, a game like Unreal has a script that's called every frame (all
the logical part is scripted), and it runs quite well :)

>
>With 200 sprites, I presume you're doing some kind of arcade type
>game - lots of stuff flashing around the screen, and the gameplayer is
>pushing his hand-eye coordination to the limit. People don't use scripting
>languages for that, except possibly for transitions.

The 200 sprites were just a test.
I intend to use the script for our engine, and having to specialize it
yet.

>
>Scripting languages are used where there is an extended storyline
>embedded in the game, such as Adventure or RPG type games. The
>script handles the storyline and transition, and the game engine handles
>everything else.
>
>For example, in Zork: Grand Inquisitor, there's a point early in the
>game where the adventurer comes across a glass box on the wall, with the
>sign "in case of adventure, break glass." The mechanism to solve this puzzle
>requires a state machine with around five states and five or six inputs,
>each
>state transition requires that the scene is updated. There are literally
>hundreds
>of such situations in the game.
>
>If you tried to do this in C or C++, with the inevitable rewrites as the
>game
>designers tried to tweak it this way and that to make the game a compelling,
>memorable experiance, you'd run through your budget in no time flat.

I totally agree... 

>
>>
>> PyObject_CallFunction( LogicalEntryPoint, NULL );
>>
>> Logical Entry Point being a PyObject* pointing on the name of the
>> function.
>
>I presume that you've made sure that the function is preloaded in
>memory at all times - it does not have to be reloaded from disk
>or recompiled from a string.


Gulp.............

Euh... I don't know how to be sure my function is preloaded, and not
on the disk... How can I do that ?


>
>> My function do only :
>>
>>     for i in range ( 0, NbTestSprites - 1 ):
>>         ListOfSprites[i].setPos( 100, 100 )
>>
>> ie it sets the pos of 200 sprites.
>> ListOfSprites is a tuple of 200 sprites, sprites is a extension class,
>> and setPos one of its method.
>
>"for i in range(...)" creates 101 objects each time it's executed: it
>has to build a tuple, and objects for all numbers from 101 to 200.
>(numbers from -1 to 100 are preallocated in the interpreter). It's
>faster if this is done once, and then passed to the for loop:
>
>foobar = range(0, NbTestSprites - 1)
>
>for i in foobar:
>
>This only works if foobar is stored somewhere where it doesn't have
>to be recreated on each call.
>

Designers will handle the scripts and I'm not sure they will use this
kind of optimisation ( using map seems a good win here too ).

>>
>> I'm using Swig to extend Python with my C functions ( I Tried Boost
>> too, but there is even more overhead... )
>
>Swig is intended to make extension more convenient. Convenience is
>usually exactly opposite to performance. Do it by hand.

Swig is not really something appearing in the profile.
but the PyArg_ParseTuple function could appear...

Thansk for your reponse, 

Emmanuel