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.
If you don't release all references to it, it will never be collected (that includes circular references if you're dealing with a reference counting garbage collector, like some IE browsers)
But in the real world, in most cases, cycles and memory is much cheaper than skilled developers. Hand coding memory is like hand coding widgets. Like on any project, sometimes optimization is necessary. I would think that mobile apps would be just like any other app. Run a profiler, see what is making the code get stuck, and fix it. When I was doing C, there were times when I had to drop to assembly because the C was too slow. It would been hugely irresponsible to do it all in assembly, but sometimes yes.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
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.
The summery mentions Python as one of those garbage collecting languages that have massive garbage collection overhead. But Python actually uses reference counting, which is a garbage collection overhead which is useful in low latency situations. 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.
Objective-C tried the mark-and-sweep garbage collection, the first program I made hung for minutes doing garbage collection, I actually had to force the garbage collector to go ahead at smart points in the program to make it behave. Having the same program using reference counting was a completely smooth experience.
This is the reason that mark-and-sweep garbage collection is not allowed on the iPhone.
This problem of mark-and-sweep isn't just an objective-C implementation problem. Java suffers from it identically, this is why it is advocated to force the garbage collector after every request on a website.
Maybe I am living in a fantasy world, but I find it insane that I have to force a garbage collection at correct moments in the program. Which is why I rather like reference counting, or stack allocation.
In Objective-C reference counting is now automated by the compiler, so it is just as programmer-friendly as mark-and-sweep.
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 approach to JavaScript development.
Everybody is to trying to use 1 library for all platforms (mobile, desktop) etc.
The first thing is to stop this non-sense.
Use server side technologies to sniff out the client. When working with mobile phones, create or bastardize a library which has the smallest footprint possible to fit your needs.
going 64-bits gets you very little with a phone that has 512MB of ram.. Personally, given the price of smart phones, they should all have at *LEAST* 2GB of ram.
Michael J. Ryan - tracker1.info
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.
Yeah, we know about document.querySelector(). It's still limited and more of a pain in the ass to use than jQuery's $().
Here's what you're going to do, son. You're going to go through these lists of library functions, and you're going to list the native equivalent, and how well it's supported by the major browsers:
http://api.jquery.com/
http://underscorejs.org/
http://mochi.github.io/mochikit/doc/html/MochiKit/index.html
We're even starting easy, and just giving you three JavaScript libraries to cover. Remember, you have to do this analysis for each and every one of those functions.
I sure hope that you don't give up once you realize how wrong you are with your bullshit claim that "every feature has a native equivalent that works across browsers".
Oh, and if you don't prepare this comparison and have it ready within a few hours, we're going to know that you're wrong and that you're full of shit, son.
Short of issues with CSS transforms and in some cases hardware acceleration in general on Android, its not all that slow really.
I have a nexus 4, which isn't low end but its no Galaxy S4 or iPhone 5 either as far as web performance goes, and for the vast majority of websites, it works just fine, with a few delays for ad-heavy sites, sites making heavy use of CSS transforms and animations (which are slow regardless of what you do with JavaScript...I'm being told the situation on iOS is much better), and a few outliers here and there that do things that could be considered edge cases. Sites using jQuery Mobile tend to be terrible, because its a terrible library, but even our main site with tens of thousands of lines of very complex and resource intensive javascript (a fairly advanced web app replicating desktop-like features) works ok, and we didn't even try to optimize it for mobile (we have a mobile specific version but it doesn't have all the features yet so its too early to compare).
But average websites like Slashdot (the normal site, not the crappy mobile one), anything google, news sites, blogs, what have you? The pages load pretty much instantly. How much faster do you really want it to go?
You're talking about "stop-the-world" garbage collection, which Python is also an example of. It doesn't have to do tracing, but it still grinds everything to a halt when it cleans up memory. I think real-time garbage collection is hard to come by these days.
Wrong. Memory on mobile is NOT cheap. Memory in a server is really not cheap (your application is only one in a many applications running, uh oh).
Religion: The greatest weapon of mass destruction of all time
You could run certainly run Ruby on any mobile device if it had a magic garbage collector that solved everybody's problems. Except there's no such thing that's immune to idiot developers who allocate memory or variables and leave reference to them hanging around. The same problems apply to java on Android.
TFS hasn't inspired me to read TFA, so sorry if it's explained there.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Generational GC can still be mark and sweep (and most of them are). Generational or not is orthogonal.
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.
I say again: Memory is cheap.
Blame the vendor.
I do not fail; I succeed at finding out what does not work.
Try running Firefox on an old XP box with 512MB of RAM and see how JavaScript chugs.
I do not fail; I succeed at finding out what does not work.
So there is something special about a memory chip built for mobile vs. a memory chip built for desktop?
Server, yes, ECC is fractionally more money. And there is a smaller market for specialized servers that may only have a few tens or hundreds of thousands of customers, so that boosts the price a bit.
But in both the server and mobile spaces, it's primarily an issue of gouging by the vendor. Especially in the mobile space where volume buying is the norm.
I do not fail; I succeed at finding out what does not work.
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.
Software bloat is a consequence of stressing time-to-market over cost. Nothing gets rewritten to throw out old stuff. Look how bloated the Linux kernel has become.
It seems to take half a gigabyte to load a web browser today. New languages don't help; "Hello world" in Go is over a megabyte.
There are reasons for needing a lot of memory. Like loading the model for a jet engine into Autodesk Inventor, which requires many gigabytes and many processors. Or loading a game like GTA V, which has a big chunk of Southern California in there. But big phone apps that don't do much? Bad programming.
One win in the phone world is the lack of virtual memory. Virtual memory has become a crutch - just bring in everything including the kitchen sink, and let the pager throw out the useless stuff. This results in slow program loads and random delays during operation. Worse, there are programs that think they're so important that they load something that sits in memory just to keep their stuff active. (I'm looking at you, "jusched.exe". If that's running on your machine, delete it. Its sole purpose in life is to keep the Java system paged into memory, needed or not. Without it, Java programs (if you run any) will load slightly more slowly when no Java program has executed recently. There are similar memory drains for OpenOffice and Windows Office.)
All virtual memory can do, at best, is create the illusion you have about twice as much RAM. This is achieved at a cost of going out to disk that's 10,000 times slower than RAM. It was a win 40 years ago when memory cost a million dollars a megabyte. Not so much now.
Just pretend I wrote a pretentious OOP/strongly typed bash session on JavaScript. Because we already know what a hot sloppy mess it is. Alas the alternatives have failed us (Applets, Silverlight...), so open wide, here comes the **** sandwich.
This is why, for anything other than very obscure and complicated functionality that would put a project way over budget, I write my own JavaScript. That includes AJAX functions, dynamic element management, form data collection and processing and all the fancy stuff that jQuery makes super easy.
Because when you use a generalizing library or framework, you trade convenience for performance and contribute to the continual problem of lazy programmers relying on unnecessarily powerful hardware.
Currently, jQuery loads 90+ KB of JavaScript and processes a whole lot of it every time you invoke functionality that uses it. Similarly capable CMS tools I've built load ~30KB of original JavaScript and only run the relevant functions when called, rather than parsing through and jumping around reams of nested and interdependent routines.
I find the added bloat better than relying on "mobile app developers" (MAD) to write error-free code in relation to memory. You can still have memory bugs with a GC-enabled language, but it's less likely. IMO, most client-side code should be written in a GC-enabled language. Everyone is attracted to writing client-side apps, but usually only intelligent geeks are interested in server-side code -- where speed and memory-efficiency matter more. Ask yourself... do you want apps on your phone to use GC-enabled languages? Have you met the typical "mobile app developer"? Do you want the language to be easier for quicker innovation and less crashes? Or do you want lean, fast apps? Of course, you can have both if the mobile device allows multiple languages. Not trying to write shill... but Ubuntu's Phone will allow writing apps in either JavaScript or C/C++ (http://www.ubuntu.com/phone/app-ecosystem). Bang it out quick and more safely in JS. If the app gets huge (and you get paid handsomely) and needs to be leaner/faster, re-write in C++.
The G
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
So I just checked, and the dragon book does agree with my interpretation that mark-and-sweep is a specific GC algorithm that is non-moving and runs in time proportional to the total number of heap blocks (live and dead). It also agrees that generational GCs are moving collectors.
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).
Ram takes power to keep running an it's a nontrivial amount. Not a real issue on something plugged into the wall but hell on battery life.
No sir I dont like it.
javascript is slow, period. It's an interpreted language. The best optimization you get is some kind of preprocessed bytecode, and that's still not as efficient as native. You might not notice this on a modern desktop, and while little mobile cpus may clock at 1500mhz, they're not much faster than a pentium 2 300.
Mobile phones have 2 major constraints that desktops and servers largely lack: Space and heat. There simply isn't that much area for memory chips, so you can't just stick in extras. There's also little to no space around the chips, so no airflow, and thus very poor cooling. The denser the chip you chose the worse the heating issues become. A lower capacity chip can be placed closer to the processor, reducing latency and vastly simplifying board layout.
Add price gouging on top of that and you get the current situation in mobile: low memory for high cost.
Not a sentence!
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'm not talking about price in dollars, I'm talking in terms of finite resource that must be shared by multiple applications beyond your application. If all applications decide that all system memory is for your personal use, the whole system collapses.
Religion: The greatest weapon of mass destruction of all time
I have a fairly javascript intense website but it is primarily used for layout etc. There is no way I am using more than a few dozen K of RAM with my variables including temp ones created in loops. Thus garbage collection and whatnot should not apply to my site. Yet my site is dog SLOW on the iOS platforms as compared to even old desktops.
And what do you think happens on a desktop or server? The memory is shared by multiple processes/programs. This is not something new to these devices. Memory has always been constrained.
But try running an old XP box with 512MB of RAM and see how your Javascript-heavy web pages fare.
It's not the world's fault that the vendors sucker you into crap hardware with only 512MB of RAM.
I'd never even consider buying such a crippled tablet or phone any more than I'd buy a desktop with 512MB RAM. It's just not enough, and hasn't been for years.
I do not fail; I succeed at finding out what does not work.
There are essentially two garbage collection algorithms: mark-and-sweep and stop-and-copy. Both can be generational, incremental, concurrent, etc.
I remember running Ruby and Java applications on a 64 meg 133 MHz Pentium machine back in 1997. They worked just fine back then. Many mobile devices today are far more powerful than that. The phone I have in my pocket (a Nexus 4) has thirty two times more memory and a CPU that is clocked eleven times faster, and has four times as many CPU cores! I don't know why VM designers (on mobile at least) don't make good use of the vast amount of research in garbage collection that has been done in the past fifty years and continue to use what amount to the simplest garbage collection algorithms that were first invented by John McCarthy and his colleagues in the 1960s for the first Lisps.
yeah, It's being slow is more to do with slow rendering of the elements currently. gradients, transforms.. all that shit is what takes all the memory, it's not exactly javascript itself in most cases - so the article is quite a bit of BULLSHIT and pretty much made just to show that iOS is better than unnamed platform xxxxxxxx.
and those gradients and css effects are used instead of hard made graphics so that the site designers don't need to do multiple sets of graphics..
garbage collected languages could and were used on mobile phones that didn't have even one megabyte of ram.. fun times.
world was created 5 seconds before this post as it is.
Articles like this simply show that many hobby programmers don't know how garbage collection works.
On top of that, following the other posts in this discussion, no one seems to realize: if you use JavaScript you are bound to GC. You can not deactivate it or get rid of it. If you want to do mobile programming in C then be prepared to be limited to certain platforms.
Back to the claim you end up with programs that allocate/claim 10 times more memory as they need to avoid GC.
Exactly that approach is the reason for slowness. A traditional garbage collector only starts running when all memory is exhausted. That means if you assign an application a big process space (like with the extra flags in a java virtual machine) you actually make your program slower! Because when the GC starts it will have to examine a huge working set (which is meanwhile all dead). Having as little memory as possible would make GC much faster, because the dead objects are much fewer.
OTOH I would not know how to do that in JavaScript.
In my experience slowness usually has nothing to do with GC but the program simply is slow by itself. People use arrays and iterate over them endless to find stuff to work on instead of a HashMap etc. They redraw the whole screen instead of the component/dialog that needs it. They assign nulls to "speed up the GC", they catch every exception and eat it or rethrow it ... instead of realizing what the error of a certain function means, they put try/sleep/try again loops around vital stuff, like fetching a file from a server or establishing a DB connection.
Or in JavaScript instead of using a tool that removes unused code from libs, they load the whole library, preferred at page load.
Anyway, I agree with other posters that we need better browsers, perhaps better DOM access or DOM models and certainly better languages than JavaScript like TrueScript and CoffeeScript e.g. or SmallTalk in the browser, that would be superb.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
If this is the case, why is the new Slashdot mobile website so javascript heavy? I simply cannot use it on my phone and have to revert to the desktop version, which runs much smoother and faster. Mobile websites should be lighter and faster than their desktop counterparts, not the other way around!
I implemented GC for the GNUstep Objective-C runtime using the Boehm collector (which, amusingly, performed better than Apple's 'highly optimised' collector in my tests, but then there's a reason that the AutoZone team doesn't work at Apple anymore...) and didn't notice any problems with pausing in typical applications, and did see a noticeable decrease in total memory usage, largely due to programs not leaving objects in autorelease pools for as long.
GC support was deprecated for two reasons. The first is that lots of Objective-C idioms rely on deterministic destruction. Although people are discouraged from using objects to manage scarce resources, you still have classes like NSFileHandle that own a file descriptor and close it when the object is destroyed. Nondeterminism of destruction made these problems really hard to debug.
The second problem was that the memory model for ObjC in GC mode sucked beyond belief. Or, rather, the lack of a memory model. It allowed mixing GC'd and non-GC'd buffers at will, but didn't expose this information in the type system. Consider this toy example:
Will this work? Who knows. If the caller passes a buffer created by NSAllocateCollectable() with NSScannedOption, or passes a buffer on the stack, then yes. If they pass the address of a global that's declared in an Objective-C source file, then yes. If they pass the address of a global that's declared in a C/C++/whatever source file, then no. If they pass a buffer created with malloc(), then no. If they pass a buffer created with NSAllocateCollectable() but without NSScannedOption, then no.
In short, the whole idea was a clusterfuck from the start. On the other hand, it may be one that's worth revisiting now that Objective-C (with ARC) has a notion of ownership for memory. Source code that uses ARC could be compiled to use GC without a huge amount of pain (although the ARC memory barrier functions seem to have been created with the express intention of not allowing GC to be added later).
I am TheRaven on Soylent News
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
yes it is - or it should be. I used to have 512Mb RAM years ago on my desktop and things ran fine. Hell, I had less than that when I first started work - I remember upgrading my dev box to 32MB RAM way back, and visual studio still ran fine.
Of course, they hadn't layered in so much crap on to it that required all the RAM is does now.
The same applies to mobiles, there are physical constraints that are not about financial cost, typically battery life, that apply to mobiles. If your app requires 2gb RAM, that means firstly that the phone must have much more than that to work effectively for the user (who will be running other things too, and if they requires 2gb as well, well, you do the math) but it also means that RAM is sucking up juice all the time. If you need that much RAM, it also means your app is not very efficient - even if its only garbage collecting,that means its doing stuff that require CPU cycles that suck up more juice. Net result - you have crap reviews for your battery-draining app and no-one uses it.
See, the modern myth that computers have so much processing power that's unused may apply to the desktop where 1 user sits there while the CPU twiddles its thumbs. It does not apply on the server where ten thousand users are all asking it to process stuff simultaneously; or on mobile where the CPU tries very hard to do nothing for as often as possible.
So, the problem does not lie with the manufacturers for making a mobile phone that requires the same form factor as a desktop
pc, complete with several fans and heatsinks. The problem lies with the programmers, not only for writing code in languages that are not designed for efficiency, but also the programmers who come up with the libraries, frameworks and other systems that are so bloated with crap because they're written from the point of view of someone used solely to coding a desktop PC that has CPU to spare and can't figure out how to write efficient code (which is understandable as they've grown up in a world of bloated crappy libraries and languages that put "ease of coding" way above anything else.
I mean, if you wrote code in C, the compiler will strip out everything that's not needed. If you write in javascript, you pull in a megabyte of data scripts from several sites, just for 1 function... because its easy to do.
Similarly, if you code for Android, in Java, you'll see your app is slow. Code it in the NDK and you'll get something very fast. (See for yourself, download Addons Detector and run it to see the development tool used for each of your apps. The fast and responsive apps will all have been written using the NDK). That shows a difference between native code and Java, imagine the difference between native code and javascript!
So use the right tool for the job. If you only know the javascript pliers, everything will look like a bent nail. Its not that js is bad, but that its not appropriate for this task.
I get your point, but I think the bigger problem is portable device users who expect a dinky little toy to perform as good as their home desktop. They need to remember it's a woefully underpowered device which is going to have trouble dealing with more than one complex task at a time -- and unfortunately for them, that includes visiting a lot of modern websites.
Were people complaining about the performance of the aforementioned 512MB PC, people would just laugh at them.
But somehow because mobile is the "new thing" we're all supposed to give a rats ass in the programming world.
Unless and until mobile devices crank up the memory (not necessarily the CPU), they're going to be second class browser citizens. Browsers are not specialized applets -- they're general purpose programs with interpreters. That means they are going to be bigger and slower than dedicated code, and there is no avoiding that.
I do not fail; I succeed at finding out what does not work.
Reread what I wrote ...
If all applications decide that all system memory is for your personal use, the whole system collapses.
This does not happen on the desktop because most applications - yet - respect the fact that they need to share resources with other applications (and the desktop pc have a lot more resources than a mobile). But try putting in the same system several applications that do not respect that, and you quickly will have an unsustainable situation.
Religion: The greatest weapon of mass destruction of all time
Having a script blocker is fine, until you discover that every website in the world has 4 or 5 or 6 or 7 LAYERS of Javascript you have to turn on to do anything with. Hell, some webdesigners decided you need to have javascript turned on to VIEW their page. Yeah there's nothing like watching the list of javscript scroll off the page and climb into the 20's or 30's. It's awesome.
Feel like giving a citation?
See, I would describe "generational" as a GC algorithm where you have separate memory spaces for objects of different ages. And I really don't see how you can do that without moving objects -- ergo not mark-and-sweep by my definition.
that's true - no-one's going to run Crysis on their mobile, but they could easily run Quake. Maybe our expectations of them need to be reduced similarly.
I do think that we will see mobiles with more RAM and power over time, they're still a very immature industry. One day I hope to see a mobile that I can dock to my TV and get a 'desktop' experience, but I still think the best way to achieve this is not to pander to poor developer's desire to have things handed to them, but to try to keep some efficiency in programming.
You can get good performance with low-RAM environments. You need to code in C, or C++ with the wonderful RAII, and you suddenly no longer need gobs of RAM for your GC-based language that assumes RAM is free and unlimited. Our problem is fundamentally down to that.
Oh interesting, seems I was wrong. You were right that when an object loses a reference, and it's reference count hits 0, it is deallocated - there's no stop-the-world there. Apparently garbage collection only happens in order to clear circular references - and that's based on the number of objects, not the amount of memory being used. Learn something new each day! Thanks.
Just read wikipedia.
Mobile is a special case because mobile devices are battery-powered 99% of the time, and are size-constrained. This means that you have optimize for perf, because you don't get an option of just throwing more CPU and RAM at the problem as we did on the desktop.
I accept that (non-moving) mark-and-sweep and generational collection are not mutually exclusive in theory. But I already said that in an aside.
All Wikipedia says is "In order to implement [generational collection], many generational garbage collectors use separate memory regions for different ages of objects". It doesn't provide any suggestion or citation of anything that talks about how you would implement generational collection any other way. What I was really asking is whether you've ever seen such a thing.
It's possible that it's actually not so hard, and it just requires knowing how remembered sets or whatnot are actually implemented to figure out how it works, and I don't have that knowledge.
I almost forgot... there's another problem discovered at XDA. Some/many/all microSD cards don't actually maintain erase counters per block... they just have a single global counter that gets incremented whenever an erase occurs somewhere (regardless of whether you're erasing 1 block or 1000), and the controller itself makes certain assumptions about your use pattern before deciding the card is "exhausted" and disabling further writes. I believe Sandisk cards, in particular, are *extremely* conservative and pessimistic about lifetime erase cycles allowed, and are the cards that caused the "wear-out" problems I was referring to. They weren't necessarily worn out and experiencing uncorrectable hard errors at that point, but WERE controller-locked into readonly mode after just a few days of swapfile activity.
It's less of a concern now, but it was a REALLY big deal back when a large class-10 microSD card would EASILY set you back a hundred dollars or more (as recently as 18-24 months ago).
Sorry, your argument is missing the point (and is imho nonsense) .
On a Desktop you have 4 to 8 gogs or even far more memory. A single application perhaps has a footprint of 1 gig, or like Chrome creates a lot of processes with one gig size. And all together they use up 100ds of gigs of swap space.
No, the idea that desktop apps "respect each other" is complete nonsense.
Every Desktop app is written with the idea: the whole computer belongs to me.
And that is what, right now, does not work on mobile platforms. But in ten years even mobile platforms will have different problems, AGAIN.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
You'll find that the bulk of jQuery use can be replaced by querySelector and querySelectorAll
it's often cheaper to refetch data from the network than it is to do a few page faults
Even if the network costs $10 per GB up or down? Prices like this are common for cellular Internet in the United States. How much money does a page fault cost?
There is a strange obsession among many that the only good RAM is empty RAM. Don;t shunt stuff out of memory until you need to
For one thing, shunting stuff out of memory involves committing unsaved changes to slow disk or slow NAND flash memory. For another, closing an application means having to call all its destructors, finalizers, or whatever your favorite language calls things that unwind in-memory data structures and release non-memory resources that an object holds. Responsiveness to user actions requires doing this sort of shutdown in the background rather than when the user is waiting for the application's memory allocation request to complete.
The article states that users expect phones to run camera applications that quickly process effects on multi-megapixel photographic images. Most people who are not creative professionals tend not to run such applications as often on PCs, especially PCs manufactured when 1 GB was standard.
then improve it where it needs improving?
A program may need improving on users' machines even if it doesn't need improving on the developer's substantially more powerful, substantially cleaner machine.
When you copy, you copy the resource.
How do you copy a non-memory resource such as a network connection? Why would you copy a resource as big as (example from article) a multi-megapixel photo unless you plan to modify one or both?
ownership usually does not need to be shared.
In an event-driven environment, it does. Event-driven environments make it much harder to predict which object will be the last object to hold a reference to a given object.
Memory is cheap today. It wasn't cheap when your user bought his device.
And what do you think happens on a desktop or server? The memory is shared by multiple processes/programs.
A server is probably running a lot more tasks at once than a desktop, and the amount of memory per task may in fact be less for a server than for a desktop. This is why an entry-level virtual private server has less RAM than even an entry-level desktop PC.
It's not the world's fault that the vendors sucker you into crap hardware with only 512MB of RAM.
The desktop box in question was probably built a decade ago when 512 MB was a lot. It shipped with 128 MB and the motherboard had two PC133 slots that maxed out at 256 MB each.
well I'm not new to networking and database stuff at all (part of my problem) but I am new to using crap like Javascript and JQuery, and web development in general.
I call it 'crap' because in my mind so much of CSS, JScript, Javaquery, JQ, etc blah blah is pure bullshit. I'm used to database queries and networking command line server stuff, and that I'm not what I'd call an expert. I used to be a hell of a data scientists and research methodologist however.
For me it is JavaScript.
I've read the discussion and I can comment on what I've seen trying to do basic Drupal and Wordpress installs and customization.
I look at the codebase of websites to learn and when I see JQuery it is used to do some flashy 'thing' that the mid-sized 'web development' company likes to show off with...and the site still has JavaScript as well.
Trying to research how to use JQuery as a geek off the street is a nightmare. So many different builds and in-house versions that go along with other do-dads that add abstraction layer upon abstraction layer in the design.
It kills me, the abstraction layers. It kills computer cycles too...just think of all the energy used to auto-play flash ads since just 2008!
From reading this discussion and limited personal experience my initial reaction to JQuery (shiny bullshit) was correct. I still don't know what to do...no programing language will work like I think it should I think.
Thank you Dave Raggett
I appreciate the insight, genuinely, but I have to comment on this:
You mean this thing, right: http://api.jquery.com/
Saw this once posted in a Gentoo/Linux discussion here on /. back in ~2001, posted to a self professed 'noob' who wanted to learn about Linux,
"Hi, I used to be like you and I suggest trying Gentoo. Gentoo/Linux is very well supported with all the necessary documentation online for you to download"
You can't **make** JQuery be 'easy for a geek off the street to use' just by referring me to some website and telling me any developer will find it useful in using JQuery.
I'm trying to make a website that lets users design their own tshirt. Yes it's been 'done' and examples are out there (customink.com, zazzle.com, etc) but they all suck.
I know basic HTML and CSS and have ALOT of CLI experience from my academic and IT work.
I get the concepts.
Now, given what I know, what would this 'API docs that any developer could read'...what would they tell me about *IF* I could even use JQuery to make what I want?
I can't believe the old 'read the docs' trope is still around....
Thank you Dave Raggett