Hey, I'm the runtime dev. Interested in your comment about GC pauses. Off the top of my head, the runtime either makes short-lived temporary objects or long-lived ones, which AFAIK is what collectors are best at. Any tips on how we can improve it?
Short-lived temporary objects are going to perform awful in Firefox until the addition of a generational GC, and will still perform somewhat badly until it goes multi-process (sometime in the distant future). In particular, since right now JS all runs on the UI thread, a user with lots of tabs open is going to have really long, painful pauses while playing a Construct game in the browser.
I'm also uncertain whether IE has a generational collector or the ability to collect individual pages separately. My current testing suggests that it might have a generational collector in 10, but it likely does not in 9 - short-lived temporaries cause awful pauses just like FF.
Even in Chrome (generational + process isolation), too many short-lived temporaries will cause you to spend a ton of CPU time in their collector running gen1 collections. This stuff adds up, even more than it does in say .NET or Java.
On mobile platforms in particular, even a generational collector with isolated processes (like Chrome) is not going to perform great because your CPU is so much slower and memory bandwidth is not as plentiful as on PC, and your processor might not be out-of-order. Likewise, the state of the art for mobile browser technology is far behind the desktop - Android's stock browser is a pale shadow of Chrome, and mobile Safari is not as solid as desktop Safari. MS is only just now rolling out something roughly on par with IE9 for Windows Phone users - WP7 shipped with a browser that was far behind the curve.
Firefox Mobile's JS runtime is not any more sophisticated than Firefox Desktop's (though, oddly enough, Firefox Mobile runs each tab in its own process, so you get some benefit there).
You should try to at least minimize the number of short lived temporary objects, especially if the total set of live objects is large. If you have a ton of long-lived objects and a complex graph, the GC is going to take time to do a full pass over the JS heap and that's going to make your pauses long enough to be noticeable. It'll be even worse if some of your long-lived objects have gotten paged out due to not being used recently - collections might have to bring those pages in from disk and will cause a horrible stall.
In some cases, a pool/freelist for your short-lived objects might be enough to eliminate pauses and remove the burden on the GC. In other cases, manual lifetime management will be too difficult/error prone and you should instead work to minimize the burden on the GC from your temporaries (by reducing their count or complexity in terms of the work the GC has to do to mark them).
P.S. If you or anyone else at Scirra wants to talk more about this stuff, feel free to contact me.