Yes, once they’re done playing.
Cool! This is without the Python profiler enabled though, right? This limits how much you can see inside “Show code”. Otherwise you’d be able to see the call graph of all the individual methods in the flame graph / timeline.
So, this is how your frame is divided up, according to the Timeline view:
I can’t see much of your Python code since you didn’t have the Python profiler enabled, but all those little blocks under “update” do grab my attention:
Are you making lots of individual calls to the collision traverser within a single frame? There might be some gains to be had there as well by trying to have those done as part of the main collision traversal.
There are other ways to improve collision performance, such as with something like this.
That said, it’s only a small part of your frame time in total. I think the main priorities should be (1) figuring out the transform states, (2) implement the sound attach/detach suggestion and (3) optimizing your Python code, these will give the most gains. After that, you can start worrying about optimizing the render loop on the right side, this will be harder.
Please note that transform states stack. If you, say, give a high level parent node a transform, and have lots of child nodes with individual transforms, then this creates unique transforms every time they are composed to form the final transform. This is why flattening can be used strategically to reduce the number of transforms. It’s interesting that this isn’t working for you, and probably worth investigating.
Are you using the Bullet physics engine with thousands of rigid bodies, by any chance? I know that Bullet also creates transform states for synchronizing these transforms.