Checking for visibility before collision = bad for CPU, don't try to optimize it?

Ashley Could you please explain this anomaly, which R0J0hound pointed out?

Logically, both events are identical, yet there's a huge difference in performance! Which I can also observe in Windows Task Manager and Resource Monitor.

Is this a bug?

I'm pretty sure it's mentioned somewhere in the docs that one should try to avoid sub-events unless necessary (probably because there's got to be some kind of overhead) but in this case the opposite appears to be true.

My guess:

The slow version runs a for each loop, and then compares and sets each Sprite individually.

In the fast version, the loop runs but doesn't do anything. The Sprites are then "collected" to bring the SOL into the sub-event, and the comparison and setting opacity is done as a single, optimized batch operation.

...in the case of "has tags", in one case you just compare a string which is a very simple and quick operation for a CPU. On the other hand "has tags" has to split the given string by spaces to extract individual tags, and then verify that all the provided individual tags are in the set of tags for the given instance. It's probably at least 10x as much work as just comparing a string. It's not that it's slow...It's just that you've used a feature which necessarily includes more complex steps. So if you make a benchmark that absolutely hammers that specific feature, you will probably see something like a 10x difference.

This is a good example of understanding "under the hood" a bit more so that we can make decisions on what to use/how to structure things.

Typical usage for any structure is going to perform great, but using "loops" or "many instances", it can be desirable to explore a different approach or understanding as many optimisation tips as possible (many small optimisations for a loop will add up).

I too went to use tags as a form of identifying many instances within loops, did measurements, and opted not to (not really understanding why it gave higher CPU than other methods). With your insights, had I wrote a bug report about Tag performance, it would have cost my time and Scirra's time to do the bug report process to ultimately end with "this is by design".

Without insights, I assumed tags was like a small dictionary hidden within instances and "has tags" automates a dictionary "has key" loop and picks objects; Didn't know that it always splits the string when using "has tags" (I've come to find heavy loops with "tokenat()" can be heavy, and try to use "Array Split String" outside of a loop when possible).

I suppose this means it's ideal to not put "Has tags" in a heavy loop, and if wanting to do different things to many instances with various tags, keep it base level with a handful of "Has tags X", "Has tags Y", and each event can have For Each after this condition, if required (often not required).

The CPU profiler is great to see usage side by side, even though it might be wrong.

When my game stutters on my M1 Mac that's when it needs optimizing, because if it has problems there, it will be worse on weaker computers.

Hard to avoid looking at this thinking I'm testing wrong though:

However Ashley you made some good points and provided interesting insight, thanks!

> Ashley: So for maximum performance, avoid "for each" unless you really need it.

Tips like this are super valuable. I think people really need something like a Construct Cookbook or CheatSheet that shows the best practices for doing things the right way.

It's a good tip, for code that can go without it indeed. I first test without and then if it doesn't work after some changes around I sadly have to resort to For Each.

I bet I could avoid it more often if I had more time to change things around more, but I need to balance finishing the project vs making it better and not having it published for some time.

> ...in the case of "has tags", in one case you just compare a string which is a very simple and quick operation for a CPU. On the other hand "has tags" has to split the given string by spaces to extract individual tags, and then verify that all the provided individual tags are in the set of tags for the given instance. It's probably at least 10x as much work as just comparing a string. It's not that it's slow...It's just that you've used a feature which necessarily includes more complex steps. So if you make a benchmark that absolutely hammers that specific feature, you will probably see something like a 10x difference.

I don't understand why it splits when it has 1 tag and no spaces. Feels like if there's a check "does it have any white spaces" it would not be so bad in performance for this scenario, but to be fair, I'd still use the instance var check.

— just like Jase00 said, “This is a good example of understanding ‘under the hood’ a bit more so that we can make decisions on what to use and how to structure things.”

It's what I've been saying all this time, every dev wants to understand more of what's happening under the hood so that we can avoid wasting time guess-testing.