Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: Python for gamedev - coding speed, performance, etc  (Read 916 times)


  • Bay Watcher
  • Love! <3
    • View Profile
    • Portuguese blacksmithing forum!
Python for gamedev - coding speed, performance, etc
« on: September 01, 2013, 08:24:15 am »

Quite a few people seem to be running into Python performance issues when programming with Python. There's been a ton of tangential discussion about this on lots of topics, so I figure getting a single thread for it might be useful.

So, what have been your experiences so far as far as performance goes? Does good, efficient code help, or is it a Python limitation?

I've been working on a smallish side-view 2d RTS with Python, and having 1000 units rendered + moving forward brings the game down to 30 fps. Having 1000 moving parts in a game is not a lot... and that is likely to go down a ton once I add AI and more complex systems. A lot of this can probably be multithreaded, which is at most a x2-x4 improvement.

There was an interesting suggestion on another thread:
I wonder how much compiling the py2exe kind of compilation can help.
you can try cx_freeze ( ).
It works way better for me to make nice exe (or variants for mac and linux).
But you won't get any performance improvements with it.

Therefor you should try PyPy ( or Cython (

I've been looking at Cython, which is very, very promising, but is a huge hassle to get working on Windows, and really changes the ease with which you develop in Python (including deploying on multiple OSs), since it adds a compilation step. I haven't tried it out yet, but since there's a PySFML-Cython, that's what I'll likely look at eventually if performance really does become a problem.


  • Bay Watcher
    • View Profile
Re: Python for gamedev - coding speed, performance, etc
« Reply #1 on: September 01, 2013, 02:41:23 pm »

I think it's important to look what is your bottlenek.

If it is rendering then your grapic engine (PyGame or such) or your hardware is not good enough.
If it is something like pathfinding then you can try to implement such specific things in c and use it from python...sure you lost your platform independence like with Cython.
Or you can look for better algorithms or better datatypes (B-Trees or using iterators when using lists or such).

Nearly all performance relevant things in Python are written in C or have a C-variant (like pickle and cpickle).

But using multiple cores is really a problem in Python. Most of the frameworks to get multithreading are focused on longer working units as one game frame.

And only to mention it you could look into Stackless Python ( Primary user is CCP with Eve Online to handle several hundred players and thousand objects in one interacting space.
GENERATION 11: The first time you see this, copy it into your sig on any forum and add 1 to the generation. Social experiment.

Inactive Therian Saga Char: Stormhead
Dominions: 4.03 Berytos; 4.06 Pangaea; 4.08 Arcoscephale; 4.11 Shinuyama
Inactive Wurm Online Char: Stormhead


  • Bay Watcher
  • Love! <3
    • View Profile
    • Portuguese blacksmithing forum!
Re: Python for gamedev - coding speed, performance, etc
« Reply #2 on: September 01, 2013, 06:19:21 pm »

That's what's kind of worrying me. Right now I've mostly got a really basic rendering system, and barely any game logic. At its barebones, all this is doing is iterating entities once and updating their position. Then it's iterating their "views" and rendering them.

I've profiled the code, and it was spending most of its time in the rendering routines, so I cached sprites and that got me from 20 to 30 fps for 1000 units. Sprites are also animated, which means the animations need to be updated as well.

I think one of the ways I'm going to optimise these systems is by having them not work as a polling system, but more of a reactive system. Systems update with run(self, dt), where dt is the time since last frame.I'm iterating everything and making all entities also execute dt, which is the simpler way to do this. For many tasks, like switching to the next animation frame, you know exactly when the entity needs to be handled next. I'm guessing switching things over to a priority queue, and popping off items as long as they need to be activated now, might make me have work only when needed. Not sure whether maintaining the priority queue is going to be more expensive than just running through all entities.

I don't really understand the problem with threading though. I imagine just having worker threads and using callbacks. If I need to handle 1000 units, split it into 4x250 and push 4 callbacks. The threads then go in and take care of it. I can probably also work on defining a process/system dependency graph and have multiple systems/processes running at once.

In general though, 1000 things on screen at once is totally enough for a ton of games. I'm also compromising some performance for the sake of nicely organised and easily extended code/gameplay. I would say that for most gamedev, especially amateur gamedev like most of us seem to be doing, using Python and pySFML is way more than enough :)