How optimal is Collisions > Overlapping another object?

Well, I did a quick bullet hell example recently, managed to get 29997 bullets on screen with about 70 fps on my PC. It uses Vector Movement.
Here it is: Please login to see this attachment.

But there's also this custom example: Please login to see this attachment.

The overlap condition is nominally more expensive than the "1-shot" collision check, but given the scenario you describe, that might be cancelled out by not having to check every bullet instance. I assume you are using a for- each loop on the bullets?

Another method you could use that might be able to reduce the amount of checks you need to do on bullets, might be to only check bullet-player collisions/overlaps on bullet instances which are closest to the player. By checking less bullets obviously you do less collision checks of either variety per frame.

LoL nevermind I misread your post. Looks like you're already checking player bullet distance. In which case you should be alright using overlaps. When I first read that I thought you were considering checking overlaps for every bullet before you scoped them by distance

No, overlap checks are usually much more expensive than simple math calculations. Typically, one might put a math condition before an overlap condition to reduce the number of overlap checks needed, but not the other way around. You could try narrowing your scope using a "is getting close....to window edge" condition instead:

Please login to see this picture.

How exactly are you testing the distance? You used the term "math", so maybe you're using a pythagoras theorem calculation or something like that. If so, try using Odistance, which I've read is the most performant method. You would still use it within the compare 2 general values condition just as you are now, but you'd choose this expression:

Please login to see this picture.

Using "Compare two general values" is usually a mistake, as it doesn't work when you have multiple instances (eg. more than one bullet). You need to store each bullet's distance in one of its alterable values, and then compare that to something instead.

"Axis-aligned bounding-box" (AABB) collision detection should actually be extremely fast, since it just needs 4 comparisons and no arithmetic whatsoever (ask yourself "Do I really need pixel perfect collision detection?" - the answer is probably "No").
Pythagoras' theorum requires 2 multiplications, 1 addition, 1 comparison and 1 square-root.

Fine ("pixel perfect") collision detection is slow, though it varies significantly depending on the shape of the objects and the extent to which their bounding boxes overlap (large objects with a lot of empty space are far worse than small, "dense" objects). When using fine collision detection, I would assume that CF2.5 uses AABB collision detection first, and then only uses fine collision detection if the bounding boxes overlap - so in practice it shouldn't be too bad.
I'm not sure if CF2.5 still uses the background collision mask system, but if it does, that might make background collision detection very slow.

To echo what Volnaiskra says, it would absolutely be a bad idea to put the overlap condition first. If possible I would try to run the for-each only on objects that qualify through distance, and then do the overlap check on each loop.

in my game I am thinking of using the collision condition for all objects first and then using the overlap. from what I see from the profiling it consumes little memory, it seems to me that calculating even the position Y between two objects is more expensive or am I wrong? also I was wondering if the "use fine detection" option is better to deselect it having many collision conditions even if they have a transparent area

Quote from MuddyMole

Using "Compare two general values" is usually a mistake, as it doesn't work when you have multiple instances (eg. more than one bullet).

OP is using forEach loops, so it's not a mistake. "Compare two general values" doesn't contribute to scoping, but it inherits scoping from previous conditions just fine.

From what I understand a combination of "use fine detection" = off, and "box collision" = on, gives the most performative results.

I personally wouldn't worry about doing too much X/Y comparisons, especially when it could save you having to do lots of overlap checks at a later stage. Fusions built-in 'arithmetic parser' (or whatever you call it X) ) can handle thousands of calculations a frame easily. At least certainly on Windows it can.