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

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: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.

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: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.

[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.

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:That's just not a viable option.

[Nerdfest]

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

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.