Ensure your worker threads aren't sitting there spinning and forcing unnecessary time sharing across your CPU. This can be solved using manual resets and signals, rather than a spin lock.
Additionally, consider profiling major portions of your code to identify hot spots, my research brings up the fact that python itself includes a respectable profiler called cProfile (http://stackoverflow.com/questions/582336/how-can-you-profile-a-python-script https://stackoverflow.com/questions/582336/how-can-you-profile-a-python-script). Use this to profile individual systems, such as your main update, rendering code, path finding algorithms, etc.
Finally, any interpreted language is going to be relatively slow compared to a direct compiled language, but your game hardly sounds intensive enough that it should be causing this problem.
Extra note When rendering anything, consider how to minimize the number of render calls. Render calls through a graphics API are expensive to make, and thus all production rendering pipelines provide methods for sorting, and batching entity render calls. An example would be rendering of a particle system. Rather than loop through each particle within a system and allow it to render itself, a system (or collection of systems) would be batched together to limit the number of texture, geometry and buffer transfers to the GPU.
Ensure your worker threads aren't sitting there spinning and forcing unnecessary time sharing across your CPU. This can be solved using manual resets and signals, rather than a spin lock.
Additionally, consider profiling major portions of your code to identify hot spots, my research brings up the fact that python itself includes a respectable profiler called cProfile (http://stackoverflow.com/questions/582336/how-can-you-profile-a-python-script). Use this to profile individual systems, such as your main update, rendering code, path finding algorithms, etc.
Finally, any interpreted language is going to be relatively slow compared to a direct compiled language, but your game hardly sounds intensive enough that it should be causing this problem.
Extra note When rendering anything, consider how to minimize the number of render calls. Render calls through a graphics API are expensive to make, and thus all production rendering pipelines provide methods for sorting, and batching entity render calls. An example would be rendering of a particle system. Rather than loop through each particle within a system and allow it to render itself, a system (or collection of systems) would be batched together to limit the number of texture, geometry and buffer transfers to the GPU.
Ensure your worker threads aren't sitting there spinning and forcing unnecessary time sharing across your CPU. This can be solved using manual resets and signals, rather than a spin lock.
Additionally, consider profiling major portions of your code to identify hot spots, my research brings up the fact that python itself includes a respectable profiler called cProfile (https://stackoverflow.com/questions/582336/how-can-you-profile-a-python-script). Use this to profile individual systems, such as your main update, rendering code, path finding algorithms, etc.
Finally, any interpreted language is going to be relatively slow compared to a direct compiled language, but your game hardly sounds intensive enough that it should be causing this problem.
Extra note When rendering anything, consider how to minimize the number of render calls. Render calls through a graphics API are expensive to make, and thus all production rendering pipelines provide methods for sorting, and batching entity render calls. An example would be rendering of a particle system. Rather than loop through each particle within a system and allow it to render itself, a system (or collection of systems) would be batched together to limit the number of texture, geometry and buffer transfers to the GPU.
Ensure your worker threads aren't sitting there spinning and forcing unnecessary time sharing across your CPU. This can be solved using manual resets and signals, rather than a spin lock.
Additionally, consider profiling major portions of your code to identify hot spots, my research brings up the fact that python itself includes a respectable profiler called cProfile (http://stackoverflow.com/questions/582336/how-can-you-profile-a-python-script). Use this to profile individual systems, such as your main update, rendering code, path finding algorithms, etc.
Finally, any interpreted language is going to be relatively slow compared to a direct compiled language, but your game hardly sounds intensive enough that it should be causing this problem.
Extra note When rendering anything, consider how to minimize the number of render calls. Render calls through a graphics API are expensive to make, and thus all production rendering pipelines provide methods for sorting, and batching entity render calls. An example would be rendering of a particle system. Rather than loop through each particle within a system and allow it to render itself, a system (or collection of systems) would be batched together to limit the number of texture, geometry and buffer transfers to the GPU.