I recommend running your code in debug mode and seeing what is using up your CPU time. It can be easy to use up your CPU budget, particularly with a large number of objects on screen. I expect your event sheet is probably using the most time.

Without seeing your project it's hard to diagnose it. There's a large number of skilled users in the community who are probably better at optimising projects than I am, but they will still need to see at least part of your project to help you.

If I have a one-screen white layout (1920x1080), and say 1000 small circles moving via Bullet and bouncing of walls and each other, and given that everything is as optimized as it gets, do you think it should be more or less handle-able on a fast computer?

I'm building a gameplay proof of concept in C3 and ran into a similar issue. In my experiment, there were new circles that were generating additional circles, which would then move to a specific location, and would be destroyed. There would be a few hundred circles (with attached arrays for state) on the screen at a time, and performance would get very bad WAY sooner than I anticipated.

I used the debugger and discovered that I had made a small mistake in my function to create my circles, and that the number of circles being created were being increased by one each time a new circle generator would be created. This resulted in many thousands of circles being created after a short period of time; they were just stacked and therefore "invisible".

I anticipate you are experiencing something similar to this, and that you'll find your issue in the debugger, because now I literally haven't been able to get a frame rate hit, regardless of how long I let the circle generators continue to be created.

> with 1-3 additional objects attached and some instance variables and calculations.

Each circle (a container) has a larger circle (as a proximity sensor), a 1x1 px anchor sprite for making sure pinned labels don’t rotate, two labels and an invisible shooter sprite that’s used for some interactions and a dictionary object (for storing genes).

There’s about 10 instance variables and more or less 20 different simple calculations “every second” on these (e.g food -1). On collisions there’s an additional calculation for pointing the shooter sprite at the colliding object.

EDIT: ah that’s more than three but initially there was only one label, the larger circle and the anchor sprite. The decline in performance at large number of instances was just as noticeable as currently though.

Good point about the debugger but unfortunately in this case the number of circles is strictly controlled and displayed on screen in a statistics box and new ones are created only sporadically on reproduction in a visible manner. So it is practically impossible that more than I know of would be created by mistake.