Slashdot Mirror
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.'"
Stop loading dozens of fucking libraries and frameworks and learn to really code.
Get free satoshi (Bitcoin) and Dogecoins
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.
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.
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'.
You could just 'force' people to use a language with explicit memory management, like by offering [better] support for that particular language (C/C++ is best but I understand people do not enjoy these lower level languages as much). I always thought that the best form of garbage collection is not having garbage collection at all, but managing your memory efficiently and having good allocators. Yet even on languages such as Java/Javascript you can be smart about your objects so to minimize the underlying allocations. I would suppose javascript may be a little harder since it's not strongly typed but it should still be possible.
Breaking news. Full story at 11.
Garbage collection is supposed to stop dumb programmers doing dumb things, but in reality it just gives them different ways to do dumb things.
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.
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.
The problem isn't that Android phones have "limited ram", the problem is that Android's garbage collection sucks miserably at dealing with short-lived objects -- a problem that was fixed & mostly a non-issue with J2SE by the time 1.4 or 1.5 came out more than a DECADE ago.
10 years ago, when J2SE 1.5 was out and its garbage-collection problem was already a historical footnote, a laptop with 512mb, 32-gig hard drive, and 700-1000MHz CPU was fairly respectable. A Galaxy S3 has a gig of ram, 16 or 32 gigs of internal flash, and a 32-gig class 10 microSD card costs $20 on sale.
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.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
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.
So looking around, it seems like "mark and sweep" does not have a single meaning. I didn't actually know this, and it means that I was wrong to say that the AC I replied to was wrong.
However, I learned "mark and sweep" (and my use is supported by this survey paper and, I believe, the second edition of the dragon book (see, e.g., the lecture 17 slides from here) though I can't check right now) to be a specific GC algorithm that basically works like an automated free() that traces and marks reachable objects then walks all heap blocks and frees any unmarked blocks. Specifically, this is a non-moving collector.
I also learned generational GCs to necessarily be moving collectors, though I suppose you could come up with some somewhat convoluted scheme that does not do this and would still be somewhat deserving of the term.
I'm not sure, but suspect that my usage is more standard.
Memory management is an issue that has me excited about Rust. Rust memory management is explicit, easy to use, deterministic, efficient and safe. The language designers understand that garbage collection is costly and that endemic use of a garbage collector limits applicability.
Although Rust does have reference counted heap objects on the so-called "exchange" heap, memory is normally allocated on the stack or on a "local" heap (via an "owned" pointer) that has "destructor-based memory management," much like C++ objects but without the leaks and wild pointers.
The result is the vast majority of allocated memory is not managed by the garbage collector. Use of the exchange heap is exceptional and explicit, yet immediately available when necessary. Otherwise, memory "management" is reduced to efficient stack pointer manipulation or simple, deterministic destruction. Compile time checks preclude bad pointers and simple leaks so common with traditional systems languages.
There is a series of detailed blog posts about Rust memory management here.
Rust was inspired by the need for an efficient, AOT compiled systems programming language that is productive, concise and at least as safe as contemporary "managed" languages. Its memory management scheme goes directly to the point of this story.
Lurking at the bottom of the gravity well, getting old
You probably mean "Memory is cheap in terms of dollars".
On a mobile device such as a smartphone, every micrometer of space counts. Every milliwatt of energy consumption counts. It's not about whether another GB of RAM costs ten bucks or so (whatever it is). It is about efficient use of space and battery.
If you add more RAM, it not only uses more energy but because it also requires space, it reduces the space available for either the battery or other components. There are numerous other reasons why memory, in a smartphone, is NOT cheap. And $$ is definitely not the main cause why people don't add that much memory (well, for some low-end devices, $$ is also a reason, but for high-end smartphones, that doesn't really count).
GC sucks, real programmers can do memory management, blah blah blah. Tell me the last time a programmer made billions because "he could memory manage" and I'll show you plenty of poorly written websites, apps, software, that suck at memory management yet still managed to become popular and used by millions.
The market decided long ago that fewer programmer hours was better than users waiting a few seconds everyday for their device to GC. Users don't exactly like it, but it works, they get their hands on a more than usable product faster.
But back to the article. In the article there's some fancy charts about how iphone 4s only has 512mb of ram. Ok, a mobile device isn't going to run with a swap file because, well, the manufacturer decided to skimp on Flash chip quality so not only does writting to flash suck, but it also runs the risk of forcing the cell to over-provision (meaning shrink in usable capacity). But iphone 4s will be 2 years old in 4 months! 2 years = EOL in the phone world.
How about a more current phone? Ok, the Google LG Nexus 4 which will become 1 year old in 5 months comes with a whopping 2GB of RAM. And its a relatively cheap phone! That's already half of my 2011 Macbook Air's RAM. Prediction? In 4-5 years, mid-range phones will be shipping with 4gb of RAM.
Ok, let's go the other direction. Let's say we all agree and programmers should sit down and memory manage again. Hurray! Problem solved? No. Because programmers are inherently bad at memory management. Memory will leak. Look at some popular web browser named after a type of animal. So instead of your phone pausing for a second to GC, now your app just crashes! AWESOME.
The standard software engineering practice still applies. Design your system. Build your system. Once it is usable and more importantly has a market, then profile for optimization.
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).
I think the biggest point against using JS libraries is that most sites load the entire library in order to use one feature. Certainly, these libraries can reduce the amount of JS used on a site/page/app - but when the entire library is loaded for a single trivial feature, the advantage is lost.
"Lame" - Galaxar
If you would turn on caching then that wouldn't be a problem.
And that dropdown menu works in the absence of hoverstate support? I'm a big proponent of doing it in CSS if you can, but Javascript is basically necessary to get menus that support touch, even if it's just by adding and removing a toggle class.
Reference counting is not garbage collection, please understand that.
E.g. a group of objects that is referencing each other, but none of them is referenced from the stack or a "global" variable will never be deleted. But a garbage collector would find those objects and free them.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Volatile memory is defined as memory that requires power to preserve its contents. All of the 'cheap' memory that you can buy at the moment is volatile memory (and the non-volatile memory is either really expensive, really slow, or both). If you double the amount of RAM, then you double the number of capacitors that must be refreshed every few nanoseconds and so you double the power consumption. You also double the amount of heat that's generated and must be dissipated.
Now, what's the number one complaint that people have about most smartphones? Is it performance, or is it battery life? If it's performance, then doubling the RAM makes sense. If it's battery life, then doubling the RAM will make people complain more.
I am TheRaven on Soylent News