What's Construct 3 Performance Limitations?

Usually the performance limits are the hardware, not the Construct engine. For example if a game only slows down on a high pixel density display, that's probably because it uses more memory bandwidth on the GPU, which is a hardware limit. The limiting factor with that is your game design, not the Construct engine.

Construct 3 actually creates the sprite sheets for you automatically. So there's no reason for you to attempt to organize your images into sprite sheets manually.

In my experiences the performance of the actual Construct 3 runtime is generally very good for it being written in javascript and running in a browser. But keep in mind it won't out perform a runtime written nativly for the device. Since everything is web tech, if you want to export your game for desktops or mobile devices, we are forced to rely on wrappers like Cordova and NWjs. Those wrappers are great to get our games out to a wider audience but they have a lot of overhead and also run the entire game/app in a webview.

I would be keen to see actual benchmarks comparing Construct 3 with a native engine. I think Construct's engine will actually be highly competitive, and it's also possible it actually exceeds a less efficiently written native engine.

Further, with WebGPU support it's entirely possible Construct can leapfrog native engines that are stuck with OpenGL.

You speak like that's going to happen soon!

Excited for that Ashley

So it depends greatly on how the engine is written. Yes, a poorly written, unoptimized engine written in C can run slower than an optimized one written in javascript. So I guess the best way to say it, for example, an engine written in C for desktop has the potential to be magnitudes faster than a browser one in javascript.

In C, memory is managed by the programmer, and can be used quite cleverly to minimize cache misses (if the programmer really knows what they're doing). There's no way to do that in javascript as far as I know.

Also, because Javascript is interpreted, it cannot benefit from the optimizations that a C compiler can do. I realize there are "javascript compilers" like Google's Closure Compiler, but those don't produce highly optimized machine code, they just output optimized javascript. Which they appear to me be more concerned with download size rather than runtime speed.

Modern JavaScript is JIT compiled directly to machine code, not interpreted. That's been the case for years. These days JS engines are so highly optimised it's generally pretty competitive with native code.