Warning: mega-post to follow:
There are two aspects to performance in C2: rendering, and event speed. Usually, the rendering's at fault. Be sure to CHECK THE DEBUGGER. Look at 'draw time'; if it's eating up a bunch of cpu, you are software rendering (chromes WebGL issue, blacklisted card, drivers...). If your cpu usage is low, but your fps is dipping, then your gpu -- for whatever reason -- is simply not up to the task.
OTOH, if you are getting slowdown from event logic -- and don't have a weak cpu -- chances are there's a glitch in your code, unless:
1. You have a few thousand moving sprites looking to collide with each other or a few thousand other sprites. If they are very spread out, the collision cells optimization should help a lot with this, but if they are all clustered in a small area, your speed won't be much better than brute force (and possibly worse). There no way around this; it's a limitation that all developers have to deal with. Try checking for cols less often, or just bring your object count down.
2. You are being irresponsible with demanding behaviors like line-of-sight, pathfinding, and physics. Again, these are demanding for all developers, whether hand coding or using a higher level tool like construct. Line of sight in particular can bring a game to it's knees if used foolishly. Like, for example, adding it to every enemy to look for the player, leaving range at default (10,000), and updating every tick (try putting it on the player, bringing range down to width-height of screen /2, only updating every 0.1 second).
Continuing on event logic speed:
All event logic is outputted as javascript. Javascript was not built to be a smooth, realtime language. It's proliferation has lead to it being developed into one, but it's been a long and arduous process. The two main drivers now are google(chrome) and mozilla(firefox), who have improved javascript performance dramatically. Without their efforts over the last 5-6 years, construct 2 would not even exist.
That being said, there are some inherent limitations to javascript:
1. It must be compiled and/or interpreted on-the-fly. This adds a greatly variable overhead, depending on what the particular javascript engine is doing with incoming code.
2. It can only run on one thread at a time (excepting web-workers, which are reletively new and very limited). Some modern cpu's have as many as 8 cores, with two threads each. In that case, your game would only have access to 1/16 of the cpu's actual capacity. That being said, most high core/thread count cpu's are either server cpu's(not suited for general use) or performance cpu's(crazy fast to begin with), and many multicore cpu's can clock up for demanding single core usage, so this is less of an issue than it might appear.
3. It has to perform garbage collection. (along with dynamic compilation, the main cause of 'jittering' in games). Asm.js can get around this, but only for asm.js code, and only when run in firefox(for now).
4. It cannot take advantage of many of the low-level processor optimizations -- ex., SSE2, SSE3, AVX -- that are available to traditional C++/assembly based applications. For certain kinds of proccesing, these can speed up execution by 10-20 times. In theory this is possible with JIT(just in time) compilers, but no one has implemented it in a JIT javascript engine. These may also be accessible at some point thru asm.js implementations...or it may be impossible. I don't know enough about this subject to have a valid opinion on usefulness or feasability.
--------------------------------
Bottom line: javascript is slower than native, but the gap has narrowed dramatically in the last few years...and with time, things will only get better.
...and on that note, here's some fresh news on the subject:
zdnet.com/google-revs-chromes-v8-javascript-engine-to-drive-high-performance-web-apps-7000026409
Okay...need sleep...<img src="smileys/smiley12.gif" border="0" align="middle" />
Cheers,
Tim