We regularly get questions like this on the forum:
"Which is faster: event A or event B?"
Sometimes they will also be asking if a specific event or a handful of events can be optimised, or if a particular behavior is faster than doing the same thing with events. Most of the time, the answer is "it makes absolutely no difference either way". You'll be wasting your time if you're worrying about it. It's like asking "which will make my car drive faster: when it's polished or when it's dirty?" - in response you think "um, neither... I guess it might be a tiny bit faster if it's polished, but the fact you asked probably means you don't really understand what's important about how fast a car goes". So let's go in to some more detail and see why that is.
Firstly, the most important performance indicator of a game is its frames per second (FPS) rate. Most modern displays update at 60 Hz, so the target of the game is to run at 60 FPS, so each time the display updates there is a new frame of the game to show. If the game runs faster than 60 FPS, there is no visual improvement! It will simply be drawing a new frame, then replacing it with a newly drawn frame before the display has had the chance to actually show it. So 60 FPS is as fast as it needs to go. That's also why many browsers don't go faster and cap the framerate at 60. Is your game already running at 60 FPS on your target machine? If so, you have nothing to gain by optimising. Nothing whatsoever. It's a waste of time. Why not spend some time improving your gameplay instead?
Secondly, games typically have two major processing jobs: processing the logic (running events, behaviors, testing collisions etc.), and rendering (drawing the sprites and objects on the screen). Our profiling has shown it's not unusual for even a fairly complex game to spend 10% of the time on the logic, and 90% of the time on rendering - even when hardware accelerated! In other words, if you're not getting 60 FPS, the #1 thing to do is think about how to speed up the drawing of the game. That might mean having fewer sprites on-screen, avoiding heavy particle effects, and so on. Remember your events and behaviors are part of the logic, which only takes 10% of the time. So even if you went to extreme pains and managed to get all your events and behaviors to run ten times faster overall, which is typically an impossible goal, you will just be reducing that 10% to 1%. The overall performance will just be a few percent better for hours and hours of work, and you could probably have got the same speed-up by reducing the rate of one of your particle effects.
The most common cause of poor rendering performance is software rendering (not using the dedicated graphics hardware to draw). On desktop systems that means your graphics card drivers are out of date, so try updating them. On mobile for the time being you'll need to use a wrapper like CocoonJS or directCanvas to get hardware-accelerated rendering. If you have poor performance, you should certainly try those things before anything else!
With a hardware-accelerated renderer, rendering is done parallel with the logic. In other words, every frame, the logic will be running at the same time the graphics card is drawing. This means the duration each frame takes to render, which determines the framerate, is whichever took longest out of logic and rendering. It's not the time they both took added together! So again even if you made all your logic ten times faster, chances are rendering still takes exactly the same amount of time, so each frame still takes exactly the same amount of time. You made your logic ten times faster but the framerate did not change. A complete waste of time!
This is partly why using a scripting language like Javascript is still fine for games. You'll see some benchmarks showing that in places C++ is 5-10x faster than Javascript. So porting our entire engine to C++ would get you up to a 10x logic speedup. But as we've seen that will often have no effect at all on the framerate. That's part of the reason we're happy to stick to a pure Javascript engine without diverting our limited resources to native ports: it's fast enough.
There are only a few select cases where the game logic takes longer than rendering and determines the framerate. These cases are usually obvious and easy to optimise as well:
- Heavy use of the Physics behavior. Realistic physics simulations are extremely processor-intensive and having over 50 physics objects can reduce the framerate, especially on mobile. Simply using fewer objects usually fixes this.
- Using too many objects. Having thousands of objects can make Construct 2 have to do a lot of per-object processing. Using Tiled Backgrounds instead of grids of sprites is usually the solution here.
- Checking for collisions between too many objects. If you test for overlap between instances of an object with 100 instances, there are thousands of combinations of pairs of instances that Construct 2 has to check every tick, which can total over half a million collision checks per second. You can either check on a timer, e.g. every second instead of every tick, or simply reduce the object count again.
- Long-running loops. Using a for-loop or repeating an event thousands of times every tick can demand a lot of logic processing. This is especially easy to do with nested loops. Again, usually it's not necessary to run every tick and reducing this to every second or just on certain triggers is fine.
That's just four points, and you can usually disregard the effect of everything else. Other things do have a performance impact, but usually it's too small to be of any importance, like the effect of polish on your car's speed. So don't waste your time. You could spend your valuable time improving your gameplay, refining artwork, or designing new levels and worlds. That's going to be a far more effective use of your time than spending time optimising things which will make no difference at all to the quality of your game.
Of course, these are all just rules of thumb. If you think something in your game is causing a big performance problem, it's easy to test: disable those events (or remove the behavior), and check the framerate. If it's a higher, bingo. If it hasn't changed, it's not important, so forget it! There's some more advice in the 'performance tips' manual entry.
Hopefully that gives you a good idea how performance works. It's not just about making things go faster, it's about judgement (knowing when or if you need to optimise) and planning (knowing what to try first). If you're wondering which of two events is faster, it's neither. Concentrate on your game!