I've worked hard to optimise Construct so it runs as fast as possible. Firstly there's the parallel drawing and event processing: the game code is run by the CPU while the screen is drawn by the GPU, so the framerate is determined by whichever takes longest (which is 99% of the time, the drawing). Essentially this means 99% of the time the game code has no effect
I don't have up-to-date figures on Construct's event performance, but my last test showed a simple event could run in 201 cycles, which very roughly approximates to running that event 15,000,000 times per second on 3ghz processors. In practice it will be less because you'll use more complex events, but it shows you can run millions of events per second. It's fast.
And as for the display performance, it's basically defined by your graphics card. My card (Radeon 9800 Pro) is several years old now and not a patch on today's technology, but it can crank out around 5,000 on-screen linearly filtered continuously rotating sprites at V-sync rate, which I don't think is too bad
Not many games will reach 5000 sprites, let alone 5000 sprites on screen at once, so I doubt that'll be a problem!
If you use pixel shaders, they are the most GPU intensive of all, especially intensive effects like blur, and these will usually be what slows down your game. You can always turn off some effects or use 'cheaper' versions (eg. additive blend instead of screen). However how fast shaders run is just how fast your graphics card is, Construct doesn't intervene other than to issue the command "draw this shader".
Essentially if your game ever runs slow, you're probably peaking the performance of your hardware, and you'll probably be doing that with pixel shaders. Still, if your game runs slow and you don't know why, gimme a shout and I'll see if I can help you