How to Reduce CPU & Collision Checks with Large # of Objects

It's difficult to help after the fact. Ideally regular performance testing would identify the particular change that caused a slowdown. It also does not appear conclusive from what you've said that collision checks are the cause of the slowdown. It's possible they're perfectly fast and something else has slowed it down. The only way you can really narrow this down is by trial and error - turn things off and see if it stays fast, and aim to find the one thing that slows things down. Then you can either optimise that, or if you think that Construct is handling it inefficiently, isolate it in a minimal project for further investigation.

A task, in of itself, for sure.

I understand the difficulty in trying to help me isolate the issue but I'll see what I can do from what I've learned. Thank you, as always! :)

Ashley - Perhaps this will help me further understand the inner-workings of C3 so I can better manage how I set this game up...

What are the - oh, let's say - five most CPU-demanding features of C3? Such as the use of Families, For Each, Picking, etc.

There was a post by one Eleanor who was quite vocal about their opinion on what aspects of Construct worked faster (eg: Picking an object specifically by UID versus Pick All). So, I'm wondering if, however remote, this could help me refine my approach to large scale numbers of objects all running on one very large layout.

It has been my understanding, further, that For Each literally runs through each instance of an object during that tick it is called on. Naturally, with hundreds, or even thousands, of objects, whether by Family (or perhaps more so because of Families), that's going to demand more CPU. But then again, generally speaking, For Each might not be so demanding. ... That's just an example of my weak understanding of things "under the hood" of this engine.

I would estimate that this list, if you can provide me with such, won't always be objectively that way - it may shift depending on how the event sheets are set up and other factors. So, I'd expect such a list may be "on average".

(I'll post this in the Discord channel, too, just in case you're not able to get back to me right away. I know you're quite busy and I always am grateful for your responses.)

What are the - oh, let's say - five most CPU-demanding features of C3?

It's impossible to answer that question because it depends entirely on what your project does.

For example 'For each' will be fast if it runs through 5 instances, and slow if it runs through 100,000 instances.

Ordinary conditions already check every instance to pick the ones that meet the condition. So 'For each' with 5 instances could easily be faster than a simple standard 'Is visible' condition that has to check 100,000 instances.

Some important points about performance are already documented in the Performance Tips manual entry, but those tend to be things beginners do because they don't understand how much work things take. The key is regular testing to catch anything particularly slow that was accidentally introduced, and guiding your changes solely by actual measurements.

That makes sense. Thank you, sir. I'll try to keep that all in mind. Hopefully I'll figure out something creative to manage the higher number of instances.