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.
 

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.

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

[Nerdfest]

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

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?

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.

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