"Why Web Apps Are Slow" - JS and Garbage Collection

I've been reading this very interesting article about javascript/HTML5, specifically performance on mobiles.

Why Mobile Web Apps Are Slow

There's definitely a lot of food for thought here. I'll be the first to say that I don't know a lot about this whole area (not even enough to agree/disagree with what the author is saying), but it's definitely something that should concern anyone using/developing C2, especially when Scirra has stated that C3 will be based on HTML5/js.

Some of the main points of the article:

-JS is 5x slower than native code

-JS is unlikely to get much faster in the forseeable future

-Garbage Collection is exponentially slower when less than 6x the memory footprint of the app is available

-You simply cannot write fast mobile code without thinking about memory management

My thoughts: in an engine like C2, it's a lot to ask for users to perform proper memory management. So in that way, C2's goals align well with JS's goals. However, the limitations of this for mobile development are very worrying.

What does everyone else think?

That isn't true anymore for iOS8 WKWebView. It's still true for Android though.

Apple's JS engine is ridiculously fast.

I have also been looking into this as of late. I actually feel the primary weakness of construct 2 is the fact that it is javascript/html5 only, which is a weak language (as far as games go) and was never meant to run games. The fact that it does run games, is something to brag about.

I think c2 (as much as I complain on the forums) is the best 2d game development bar none. Its fast, flexible, and intuitive... It gets harder to work with bigger projects but that can be fixed.; what can't be fixed though is a javascript game... oh it's fine and dandy for every flappy bird bird game that will ever be made... but idk.

I just get gut sick when I watch the game janking and have no power to stop it. And then I find myself in unity, wishes construct didn't output javascript. The real question is can you live with the limitations jscript sets. If so, nothing to worry about.

— ... but will it ever beat c++?

I read it before (not sure if it was edited between the time I read it and the today), and my opinion is still the same and will not change anytime soon if the arguments also don't change:

Javascript sure is slower (and on what I saw, well, it is outdated and so weird that most people do not use directly Javascript but some libraries to help them). And it is an interpreted language which does not belong to a single interpretor, all of that is to take into deep consideration... unless you are not directly using javascript, in which case you should see what is already done to help.

In the case of C2, memory management and garbage collection issues are seriously lowered (due to general kind of recycling and layout by layout loading, as well as a lot of other things that I am not able to describe that may have been done), and the fact remains: Javascript performances are tied to how it is interpreted, on mobile I saw that, well, compatibility seems to be an issue so I would guess that we are far from what could have been done, yet, it is pretty doable.

All of this should be taken into consideration before buying C2 for obvious reasons (and you can test before buying it, C2 is fully html5 + javascript and does not rely on native at all, the event system should not be the only reason you are using C2 for, if html5 is not interesting to the potential user, then he might as well not buy it). If you need native, you won't even consider javascript anyway.

As for an html5 C3, keep in mind it is not before at least 1 or 2 years (and while JS performances does increase, as well as compatibility, which means it will be realisable, and before CC anyone though that a free drag n drop engine was just a toy, before C2 they though that html5 was doomed to failure and that nothing serious could be done with it, they might as well prove that a game creation engine can be done to run inside a browser without plugins) it is imaginable, heck even gdevelop as a web app nowadays (in a beta stage), sure it is not useable for a full fledged game and confusing, but this is because it is just weirdly designed, not because of perfs issues. However for obvious reasons when C3 does arrive, users should do the same they are currently doing: test carefully on a range of browsers so bugs are not left behind, also C2 already is a stable engine so the global design of it may be "easy" to transpose into the C3 editor.

however time will tell.

Ruskul I do agree that it would be nice to not have only javascript (due to how C2 plugins works, after all, there was a time when developping your own exporters was on the todo list if I recall), but well, no obligations, if other engines do better, fine for them.

First I test my app on Crosswalk - jittering (smooth on CocoonJS but there still no native AdMob = I'm loosing money)

then I read posts about Crosswalk slowdown with AdMob ads,

then I read Ashley post "Crosswalk provides good support for Android 4.0+", "We recommend moving away from the non-browser platforms and transferring to the Cordova-compatible platforms as soon as is practical."

— ... but will it ever beat c++?

You mean Objective C?

Don't know, but its a heck of a lot faster than the JS engine in Chrome for PC.

To put things into perspective, my game (constant 60 fps) uses ~20% of my Intel i5-3770K for battle scenes on Chrome or Node Webkit. The same build running on an iPad Mini 2 WKWebView uses ~15% of the Apple dual-core SOC. We know in raw processing terms, the iPad Mini 2 SOC is waaaayyyy behind a beefy i5-3770k.

For comparisons sake, non-WKWebView or with CJS Canvas+ (pretty much the current Android situation), the same battle scenes load the Apple SOC 100% and fps dips to ~40.

It's hard to address such a long article but some key points are:

• it was written in 2013 and there *have* been big improvements since then anyway - such as just one improvement being the new FTL JIT in Safari based on native compiler technology
• mobiles are always getting faster and more memory - 2GB devices are now common
• modern browser GC is incremental, parallel and generational, designed not to cause frameskips
• the C2 engine is GC optimised anyway: it tends to allocate what it needs, then continuously recycle the same objects, so there is never much garbage to clean up
• very carefully written JS code can approach native speed within the body of a function. JS has overhead in between method calls and lookups on dynamic objects, but if you have a function body with local variables, fixed types and tight loops, there's no reason the JS engine can't JIT that nearly as well as if it were C code.
• even performance-demanding games are often not actually CPU-bound at all, and bottlenecked on GPU rendering which happens at exactly the same performance as a native app, so faster JS execution would not actually help.

I don't disagree with all of it - I don't really like garbage collectors and would prefer to write an engine with explicit control over memory and completely eliminate the possibility of pauses - but I don't think it's as bad as it makes it sound. Just the improvement since the article was written alone is cause to rethink it.