I'm not sure it's helpful in this case but i did some test a while back and noticed that just picking objects with events (conditions) becomes quite heavy when the number of objects increase, even on static objects. So i found out that some conditions were more efficient than others in terms of picking, but in general trying in smart ways to limit the amount of picks using certain conditions, some ways were more CPU friendly than others.
For example. Let's say you have a huge layout, with tons sprites in a certain family. Just picking by family across the whole layout can be quite heavy, even without any actions applied.
This is what you want to limit. Let's say you use the condition "is on screen" to first filter the things that are on the screen. That's a pretty good filtering right there and works quite well. But in some cases even the Line of sight behaviour (without obstacles) set to a radius a bit bigger than the screen width can be even cheaper than the "is on screen" condition. But so far the cheapest way i could find (in some cases) was using it in reverse. First pickin "is not on screen" or reversed has line of sight to, then picking pick nearest. It only applies actions to that particular sprite, that just became closest to any of the screen edges.
I don't know why this particular condition. "Pick nearest" is so cheap, even if you have large amounts of sprites in a layout. I use that condition A LOT. I would like to know how it works, because it can't possible check the distances between every object in layout, that cheaply.
Another good way, was to have one dedicated event setting a boolean value to every object that is on screen or has LOS. That way you don't have to use "is on screen" again in other events to pick by that, because picking by a boolean is way cheaper that picking by "is onscreen". the same amount of objects.
Here's some testing i did using different kind of methods for picking just to check how heavy they are performance wise, picking from 200 sprites.
Hope that helps.