Why JavaScript On Mobile Is Slow

An anonymous reader writes "Drew Crawford has a good write up of the current state of JavaScript in mobile development, and why the lack of explicit memory handling (and a design philosophy that ignores memory issues) leads to massive garbage collection overhead, which prevents HTML5/JS from being deployed for anything besides light duty mobile web development. Quoting: 'Here’s the point: memory management is hard on mobile. iOS has formed a culture around doing most things manually and trying to make the compiler do some of the easy parts. Android has formed a culture around improving a garbage collector that they try very hard not to use in practice. But either way, everybody spends a lot of time thinking about memory management when they write mobile applications. There’s just no substitute for thinking about memory. Like, a lot. When JavaScript people or Ruby people or Python people hear "garbage collector," they understand it to mean "silver bullet garbage collector." They mean "garbage collector that frees me from thinking about managing memory." But there’s no silver bullet on mobile devices. Everybody thinks about memory on mobile, whether they have a garbage collector or not. The only way to get "silver bullet" memory management is the same way we do it on the desktop–by having 10x more memory than your program really needs.'"

Comments

Easy

[ArcadeMan]

Stop loading dozens of fucking libraries and frameworks and learn to really code.

Re:Easy

[Anonymous Coward]

We already know how to "really code". We just got sick of reinventing the wheel every time we start a new project. Now we let the libraries do the tedious crap, and we focus our attention on where it's actually needed.

You're going to use our library-heavy code, and you're going to like it. You already do, in fact. You're lying when you pretend otherwise.

Re:Easy

[girlintraining]

Stop loading dozens of fucking libraries and frameworks and learn to really code.

If memory management was so easy, we wouldn't have devoted so much of our programming guides, style manuals, etc., to it. It's not a simple matter of "I wave my hand and the problem goes away." It has existed since before there were "dozens of fucking libraries and frameworks" and at a time when people did know how to "really code"... it has existed since the very. first. computer. And it hasn't been solved to this day.

The main reason, I suppose, is the same reason why we haven't yet found The One True Concrete that all things can be built out of, or the One True Operating System upon which everything can run, or the One True... you get the damn idea. Men much smarter than you have devoted their entire careers to trying to solve the problem, and it's incredibly pretentious of you to toss off a one liner like it's (puts on sunglasses) just a simple matter of programming.

Re:Easy

[Anonymous Coward]

Stop loading dozens of fucking libraries and frameworks and learn to really code.

Because *REAL* programmers don't use libraries or frameworks. In fact, *REAL* programmers don't even use wussy text editors like vi or emacs; they use butterflies.

Re:Easy

[loufoque]

Memory management is easy. Just program in C instead of JavaScript, problem solved.

always

[Spaham]

You always need to think about memory. Like you need to think about what you're doing.
Too bad for the "write app get rich" idiots.

Re:always

[Anonymous Coward]

I write C code all day everyday and never once worry about whether something will leak or double-free. You quickly learn patterns which make object lifetime management safe and simple. In C++ they generically call it RAII. But the basic patterns are simple and are trivial to follow in C, there's just less syntactic sugar (which often is a good thing because you then tend to economize).

The number of times I've leaked memory in C is probably less than I've leaked memory in a GCd language (yes, you can leak memory in GC). If memory management is anything more than a simple chore, then you're doing it wrong. It does take practice, though.

Don't get me wrong, I also use mark+sweep (e.g. Lua) and reference-counted (e.g. Perl) garbaged collected languages. Good times. You just can't use a GC'd languages for anything that will use a lot of memory in a single process. This is why people complain about Java all the time. The time spent walking the object tree grows faster than linearly. The article is fails to grasp that point, although the Microsoft C# engineer nailed it when he mentioned that object references can grow exponentially. The reason why more memory makes it seem like GC is faster is simply because with more memory you can just let junk sit around longer, and then destroy the entire heap all at once. At least, for web pages, which tend to be ephemeral. That doesn't work well for long-lived server processes though, in Java or C#, which can't avoid constantly cycling through all memory.

If you must use a GCd language for memory intensive stuff, you need to use multiple processes and IPC, not just threads, so you can partition your heap memory. Partitioning that way will improve GC algorithmic performance better than linearly. Unfortunately Java and C# don't make multiprocess architectures as easy to implement as in Unix+C, where you can create nameless socket pairs, pre-fork, and pass file descriptors, etc, over the channels, all without polluting any external namespaces--i.e. no loopback ports or temporary files.
 

Re:always

[EvanED]

The reason why more memory makes it seem like GC is faster is simply because with more memory you can just let junk sit around longer, and then destroy the entire heap all at once. At least, for web pages, which tend to be ephemeral. That doesn't work well for long-lived server processes though, in Java or C#, which can't avoid constantly cycling through all memory.

It's more than that though, and it's not just that it seems faster -- it is faster. And it's not just because your program may end before needing to collect or something like that.

The reason that GCs are memory intensive is because of the design of good GCs, which are usually generational. They have multiple memory spaces, and move objects between them. The presence of those spaces are what increases the memory requirement, because you need to make them big enough to contain a bunch of dead objects too or you'll hit the performance wall I'll talk about in a second. The GC will actually move objects from one space to another.

The reason that having too little memory hurts is not just because your GC runs more frequently, but you start losing out on the benefits of having those multiple spaces. The division between long-lived and short-lived objects starts to diminish, because an object doesn't have to live as long to get promoted to the next generation. You might promote objects to the oldest generation sooner, and the older generation loses out on some of the mitigating reasons why GC doesn't have to be so bad.

In short, GC actually works well speedwise even for long-lived processes, in spite of them churning through memory. They just need more memory (3-5x) to get the same performance.

That's just not a viable option.

[Anonymous Coward]

Since JavaScript is so damn lacking, those libraries are ESSENTIAL for anything beyond the smallest JavaScript app.

Even if you don't use jQuery, for example, you're going to need to find and then use some other library that does the same thing, or write a whole shitload of code yourself to implement the same functionality. Zepto works as an alternative for some people, but even it still has some overhead.

That applies to almost anything you want your app to do. If you want to work with objects, arrays or even strings in any way beyond the simplest of manipulations, you're going to need to use some third-party code, or write a whole lot of it yourself.

JavaScript developers are so wholly dependent on these third-party libraries because the JavaScript implementations themselves are so bloody lacking. It's totally different than a language like Python, where there's a rich, yet still compact and efficient, standard library that developers know will be available on just about every user's system. JavaScript programmers have to provide this basic infrastructure with each and every app they write.

Re:That's just not a viable option.

[ShanghaiBill]

Even if you don't use jQuery, for example, you're going to need to find and then use some other library that does the same thing

Furthermore, popular libraries like jQuery, Mobile-jQuery, etc. are much more likely to have clean, efficient, memory-lite implementations that some "roll-your-own" code. If you choose your libraries carefully, learn to use them, and avoid "rolling-your-own" unless really necessary, your code will certainly be smaller and cleaner, and usually be faster, smaller, and use less memory.

Re:That's just not a viable option.

[bucktug]

I really do appreciate a good framework... My favorite one currently is Vanilla-js http://vanilla-js.com/

Check it out. Amazing performance.

Re:That's just not a viable option.

[Nerdfest]

Learning a flaky, inconsistent language is only prolonging the problem. The web needs to move to something sane. As I said to someone the other day, it's extremely sad that the two most popular languages used for web development are two of the worst languages around (JavaSCript & PHP). It does go a ways towards explaining the quality of web software in general.

Re:That's just not a viable option.

[amicusNYCL]

You'll find that just about every feature your "essential" library provides has a native equivalent that works across browsers -- even as far back as IE 8.

That's a pretty naive view that over-simplifies the situation. One major use for a framework, for example, is to normalize the behavior of different browsers. Another major use is to provide implementations to create interface elements. Now, obviously, everything is natively supported because the Javascript framework is right there doing it, natively. But why should I write the necessary logic to create a draggable window, or a tree view, or sortable grid, when I can just pull that in from a framework? ExtJS is the kind of framework I'm thinking of. Why should I implement ajax-style uploads inside an iframe when they already did that for me, and I can just set up a form panel, indicate it is a file upload form, and write the important stuff?

Even though I can use a massive ExtJS application on a phone, we're not talking about massive applications per se, we're talking about mobile Javascript. So there are things like Sencha Touch for that. Sure, I could write native applications for every device listed under the supported devices section, but why is it smart to do that when I can write a single codebase that I can package for multiple devices?

Or maybe I'm just not "familiar" with Javascript, or development concepts in general. Hopefully you can enlighten me on the merits of reinventing the wheel every time you create something.

Re:That's just not a viable option.

[mypalmike]

> Yet C developers... rarely depend on shitloads of libraries.

$ ls -l /usr/lib | wc -l
shitloads

Re:That's just not a viable option.

[snadrus]

The last major jQuery jump dropped IE8 & older support because there were too many quirks they didn't want to bloat everyone's use of the lib with.

Re:That's just not a viable option.

[Nerdfest]

Compared to those other two, Java is a dream language.

Re:That's just not a viable option.

[Anonymous Coward]

How is this informative? My guess is that it was modded up by people who, like the poster, have only basic experience writing JavaScript.

When you're writing code in any language as a hobby or just getting your feet wet, you love the simplicity of minimal overheads and writing everything yourself, because of course you can do a better job than all the other shmucks. When you're writing code for a living or you advance beyond variations of hello world, you come to realise that you're not actually more enlightened than the pro's and that frameworks actually do make for more maintainable code which is cleaner and more efficient than you could have written yourself, as well as more rigorously tested and secure. When you're writing significant code, you see, you are taking advantage of large parts of the core of all frameworks, which you would otherwise have had to reinvent yourself in a far poorer fashion.

In short, if your needs extend as far as simple form validation, maybe the framework is overkill, but once you're starting to write substantial web (and non-web) applications, you'll really learn to appreciate frameworks. Frameworks are also used widely for simpler sites because no-one is prepared to pay you to reinvent the wheel. In these cases, one can usually take advantage of subsets of Frameworks, to avoid loading lots of unnecessary code.

For what it's worth, this argument applies to all languages, and you won't find any sensible programmers writing directly to win32 or X api. Instead, they're using .NET, GTK, QT, Wx, etc. because they know that they would spend their life writing essentially equivalent implementations themselves to cover the features that they need. Sure, one might use win32 directly for a simple utility (been there recently, in-fact), but not for any serious application.

Re:That's just not a viable option.

[phantomfive]

Try picking a random package and getting to cross-compile for a platform like, for example, Windows. You'll suddenly realize how many dependencies there actually are.

Re:That's just not a viable option.

[Rockoon]

JavaScript is "flaky" and "inconsistent"?

What on earth are you talking about?

I think that hes talking about JavaScript being flaky and inconsistent.

Re:That's just not a viable option.

[Kielistic]

I'm giving up moderation to post this but it has to be said. You keep claiming jQuery is slow and crappy because a few frameworks that exist on top of it are slow. Both jQueryUI and jQueryMobile are designed to completely change (and unify) what the browser controls look like. Of course they are slower than native. I even went to your little site and ran this one : http://jsperf.com/jquery-body-vs-document-body-selector. jQuery came up about 5%-6% slower than native. If you give up a unified, well tested framework and a tenth of the development time for a 5% speedup you are either working on something very special or need to be fired immediately.

jQuery is not a performance killer. If it was you wouldn't see it on nearly every website more complicated than "hi my name is narcc". What it does do, however, is cut development time considerably. Provides a consistent experience across most browsers and gracefully falls back when browsers don't provide native solutions. And provides far more web-specific features that Javascript does not (otherwise people wouldn't use it).

I won't claim that jQuery is faster than every native solution. But it is probably faster than your native solution. And infinitely more maintainable.

Just for fun: Just look at how readable and maintainable that code is. I'd love to try to figure out why a $100000 web-application isn't working in BroswerX 10 months after somebody else wrote it written like that.

Additionally: if you are doing 2+ million operations than yes maybe you might want to devote some time to writing a specialized function. But normally you're only doing less than 50 on a fairly complicated web-app so your benchmarks won't show too much of a difference there.

Just for my own fun. What happens if you go : document.querySelector('.menu > a:last') in IE9?

Re:That's just not a viable option.

[Kielistic]

Or do you mean code written using jQuery? Now that's impossible to maintain! (For reasons mentioned earlier and later.) Add to it that jQuery code is mostly written by amateurs who don't know any better (or professionals that don't want to face the simple fact that JavaScript is not C# and they'll need to learn some new concepts). When you see jQuery, you can safely assume that the code is a mess anyway.

Pure bullshit. Ignoring the glaring fallacy of "I've seen amateurs do bad things so jQuery is bad" I will just comment on it being difficult to maintain. Javascript in general is difficult to maintain in a large web application. jQuery makes things easier because it provides a fairly consistent syntax for common things you would likely do in a web application.

Oh, and did you hear? They're dropping support for IE8 and below. Not that it did a great job of supporting those browsers anyway, but it's yet another reason that jQuery has LONG outlived its utility.

Their future branch has cut off support for legacy browsers. This is for people who don't need them and to ease production of new features. They still maintain the 1.x line that fully supports IE8. This is where it is clear you are talking from inexperience and flat out lying to avoid admitting you've been less than truthful. It is very rare you ever see jQuery do something inconsistently between the common browsers. Definitely less than you see vanilla javascript being inconsistent.

The ONLY reason you see jQuery used today is that those same developers never bothered to learn JavaScript. They assume jQuery saves them time and effort (it does not, it costs them time both early and in the long term) because that's what they were told years ago.

Explain how jQuery doesn't save time? It is a framework that provides common functionality that people want from Javascript. So without a framework your options are to re-write that functionality every time you want it or build your own framework. Both of those options will be less maintainable in the long-run and far more bug-prone (being less tested etc). You can't just keep claiming "jQuery bad; reinvent wheel good" with some handwaving about performance and amateurs and blathering on about how much smarter you are for using vanilla Javascript instead.

Fortunately, developers are starting to realize that they've been fooled and are actually starting to learn JavaScript.

Or maybe Javascript has started to become consistent enough and functional enough for specific tasks that people can easily use it for simple tasks now. People that don't have to worry about any kind of legacy support that is.

With any luck, by 2015 we might not have jQuery bogging down the web.

With any luck by 2015 we won't have Javascript bogging down the web. It is a language that is not a good match for what it is used for in this case.

Only a short-term problem

[s7uar7]

The only way to get "silver bullet" memory management is the same way we do it on the desktopâ"by having 10x more memory than your program really needs

Give it a couple of years and that's exactly what will happen. Problem 'worked around'.

This is what's going to doom FF OS

[slacka]

This is one of major flaws behind these Web based Mobile OS’s, you think that after WebOS, beautiful as it was, Mozilla would have learned their lesson. Instead, they’re trying to drive underpowered hardware with a HTML/JS. All the web technologies are being shoehorned into areas they were never designed for. From DOM being used for Applications to the lightweight scripting language, JavaScript, being used for Apps, to a bloated HTML render as the platform's UI toolkit.

JavaScript is a nice little scripting language that’s got some nice functional programming features. When you need to need to write heavy applications that require performance, low memory usage, and multithreading, it’s the wrong choice.

Re:CPython uses reference counting, like objective

[EvanED]

As opposed to the standard mark and sweep garbage collecting like those in Java where every few seconds everything grinds to a hold to clean up memory.

Not to say that tracing collectors don't have a bit of a stuttring problem and I don't want to get into tracing vs reference counting, but:

1) Decent tracing collectors (and the Java VM has had one for a while) are not nearly as bad as you make them out to be, and

2) You mean "tracing collector" rather than mark-and-sweep. The latter is just the simplest form of tracing collectors, which is really pretty bad and is essentially never used. The JVM uses a generational collector, .Net uses a semispace collector (I think), all three of which differ pretty significantly in both mechanics and performance characteristics.

The second point is a bit pedantic and in many stories I probably wouldn't even reply, but in a discussion that is basically specifically about GC it is a good idea to use correct terminology.

A lot depends on what you're trying to do...

[ducomputergeek]

Most the "Apps" I'm being hired to write are basically CRUD form apps that are designed to read info from tables in a database. Usually to take forms already in use by desktops written in Java or .Net or in some cases god only knows what and adapt them for use on mobile devices.

I've frankly found jQueryMobile + HTML5 + Phonegap/Cordova makes this task farily easy to undertake client side. Actuallly in most cases the cost is still developing and deploying the API side in your choice of server side scripting language. And often that's based upon a perl script that I wrote circa 2000 to take form input, validate, and then go fetch data from a database and return in XML, YAML, or JSON these days. Other projects, the server side is in PHP or C# or Java. Just depends on what the client already has.

Now I can see trying to buld other types of apps using HTML5/JS is asking for disaster.

Sorry, I'm an old perl guy who thinks use the right tool for the job and there is still more than one way to do it.

Industry trade secrets revealed

[WaffleMonster]

I've found the best way to get developers to stop being lazy is to give them shit hardware.

The mistake is buying the latest quad core 2GB android goodness... Give them a 5 yr old piece of shit and the resulting mobile apps will rock.

Re: Mobile is not a special case

[Miamicanes]

10 years ago, desktop computers didn't page to hard drive sectors with half-lives of 100k writes or less, and siphon the bits through a single-bit (SPI/MMC mode) or 4-bit wide (SD-mode) cocktail straw. As a few guys @ XDA learned the hard way, micro-SD wear-leveling is NOWHERE close to being as robust as what's in a desktop SSD, and onboard flash (like what's in the Nexus 4) might not have "SSD" logic *at all* (leaving its management *entirely* up to the OS to cut costs). Vigorously swap to a mostly-full microSD card, and you can *literally* push it into "hard error" land and end up with weakened cells in just one single weekend of aggressive benchmarking. Blindly swapping to internal or microSD flash desktop-style is NOT consequence-free, and is *totally* unsafe to do on any phone without microSD (at least end users can toss & replace a worn-out microSD card).

Re:Article itself is a waste of memory

[TopSpin]

The market decided long ago that fewer programmer hours was better than users waiting a few seconds everyday for their device to GC.

No, actually, that's not what happened. As the summary and the story itself (both of which went unread apparently,) point out, one of the most successful systems to emerge in the market recently, iOS, is not a GC environment.

Over here you may learn about iOS memory management. Without getting too far into that wall of text one discovers the following:

If you plan on writing code for iOS, you must use explicit memory management (the subject of this guide).

Ok, so your claim that GC is the only viable solution for contemporary application development is demonstrably false. Lets look some other assertions:

programmers are inherently bad at memory management. Memory will leak [if programmers must manage it].

First, the vast number of iOS applications not leaking shows that a non-GC system doesn't necessary have to leak. At least not badly enough to compromise the viability of the platform, which is the only meaningful criteria I can think of when it comes to the market.

Second, why assume programmers are inherently bad at a thing when that thing has traditionally been exposed via terrible, error prone, demonstrably awful mechanisms? It seems to me that among widely used tools we leaped from 'systems' languages with truly heinous MM primitives (C/C++) directly into pervasive GC systems. Aside from Objective C+ARC there just aren't enough good non-GC systems to make broad generalizations. Thus, you may be right about programmers, but you can't prove it, and I doubt it.

Finally, what proof is there that pervasive GC is better at not leaking than a good explicit MM system? Anyone with an Android system and a bunch of apps will quickly discover that pervasive GC does not eliminate leaks.

[some phone] comes with a whopping 2GB of RAM

Goggle Glass has 682mb of RAM. There is always a new platform into which we much fit our software and the new platform is usually resource constrained, so there will never be a day when questioning the cost of GCs is wrong. Maybe the wearable you eventually put on will have 8 GB of RAM. The computers you swallow or implant or sprinkle around the lawn probably won't. The fact the next generation of phones can piss away RAM to greedy GCs just isn't particularly informative.