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'.
NOW!!!
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.
Memory is cheap. Even for mobile devices. But the vendors want to bend you over backwards for every gigabyte.
So put the blame where it belongs: on those who would restrict memory arbitrarily.
64-bit processors are the norm nowadays. Screw anything constrained by 32 bits.
I do not fail; I succeed at finding out what does not work.
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.
Don't make the consumer pay (in battery life and frustration) for fad frameworks and poor coding practices. A company pays you (who in turn is paid by the consumer) for something Good.
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.
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.
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.
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.
Little computers are essentially the same as bigger computers were, a few years ago. If garbage collection was ok on the desktop in 2003, then it's ok on mobile. If it's not ok on mobile, then it's wasn't ok when you learned python. Anyone who does a split decision on this is either a hypocrite, or has to admit we're in some kind of brief transition period where mobile either just recently grew up or is about to.
And yes, garbage collection is ok, because having 10x of the memory you need is ok, because memory is dirt cheap and anyone who is running out, is either a pussy or else they're doing their nuke sims on their phone and need to stop that. Wrong tool for job, LANL-man.
Everybody and their dog is pushing javascript/html5 as if it is some kind of panacea and guess what happens. They discover that it isn't the OS unifying silver bullet they hoped for. More like a new C++ (the first version from the 70s) for the web. Everything about JS is still garbage: Memory footprint, the tools (or lack of), debugger, profiler, the JS web developer mentality, it even lacks basic support for stuff like imports/includes of javascript files.
I really look forward to five years in the future when there is an abundance of crappy javascript/html5 business applications nobody sane would want to maintain. It's like Java Applets all over again.
Yeah FUTURE!
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
one thing that i have noticed is that websites load faster when i turn JavaScript off on my iPod touch. of course, i loose like 75% of a website's functionality. grrr...
Search engines don't work right and most menus on websites don't work. even websites designed for mobile devices use javascripts. i can't find a text-only version anywhere. just saying.
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.
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.
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.
look at j9 realtime
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.
Ever since they "upgraded" it to use shitloads of javascript to dynamically load content.. it's been absolutely unusable on my phone. Absolutely unusable.
But python stops the world for a short time, only at the time an object loses reference. Therefor it is a lot more predictable when garbage collection happens, and more smoothly averaged over the execution of your application. I am not talking how python uses a mark-and-sweep when dealing with circular references.
Objective-C does mark-and-sweep in a separate thread and is able to garbage collect without stopping the other threads. However in my case it was too slow to follow my program. My program was creating objects for a calculation and once the calculation was finished removed the objects. The objects were rather large as they were full HD RAW video frames. After a few calculations the memory was full and my computer started swapping.
With reference counting this doesn't happen because when you lose a reference on an object it is immediately removed.
There are essentially two garbage collection algorithms: mark-and-sweep and stop-and-copy. Both can be generational, incremental, concurrent, etc.
and I'll rip your heart out
Maybe its also because Safari SUCKS DOGS BALLS (no ad blocking, no proper tab management, etc) - and Apple have nobbled any other browser's javascript support.
F***ing Apple piss me off. Either Fix Safari so it's better than a TOTAL PIECE OF SH**, or let all browsers use un-nobbled javascript. Jobs is gone, so you can stop with the fascist draconian BS.
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!
Yeah, yeah, it's an issue now but the devices are getting faster and more powerful by the year. This is a temporary problem that technology will solve in the long run, we're just at the beginning of a device that's evolving very quickly. Don't loose sleep over it.
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
I hate to break it to you but there is no silver bullet on desktops either.
With garbage collected systems you can leak memory.
It's just that you leak memory in a different way to deterministic systems (and when you do it's harder to identify with a GC'd system).
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 run browsers and javascript just fine. So I still don't see the excuse for these phones. Javascript is a repackaged Lisp and Lisp has been around for 50 years. Emacs Lisp ran fine in 1 megabyte computers (microvax 1). Well maybe not fine, but usuably, and 2-4 megabytes was enough.
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.
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.
Javascript has to take its place in history for the unprecedented holocaust of quadrillions of cpu cycles.
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.
Read through the blog post and some of these comments.
I'm a bit confused. We solved the garbage collection problem for embedded and realtime devices
a decade ago. Right now, there are plenty of mobile handheld devices using our technology to
run applications written in Java (although could as easily be other languages).
They don't need massive amounts of memory. Well, to be realistic, we could
fit in a large microcontroller, and have, but it takes a bit of work, Systems with 128 MB, 512 MB are
plenty sufficient for system level, device access, computational and graphics applications.
I would agree that the smartphone industry doesn't have this. But that is simply an
artifact that the smarthphone industry went with Objective-C for iPhone - no GC, and
with Dalvik for Android - poor GC (and maybe not so great performance).
On the discussion about Javascript, yes its an interpreted language.
JIT'ing it improves it. Using the approach we use instead of JIT'ing
would improve load time and runtime. I don't know what the GC implementations
for Javascript are right now. I know that our GC technology is not in use for
Javascript yet.
The issues of "non-hiccuping" garbage collection have been solved for quite a while.
We eliminated stop-the-world events. GC can be multicore, multithreaded, parallel
and concurrent. The problems of compaction and fragmentation have been solved.
The problems of non-preemption have been solved -- the GC is preemptible.
Yes, a well coded C program can most likely outperform the
best "managed code" environment. But I can beat a C program with handcoded
assembly language (or could at one time when I wrote in multiple assembly languages).
Throughput performance that is in the same range as C/C++ has been shown with
benchmarks -- meaning ranging from similar to 30% additional overhead,
and this could be improved with additional compiler technology but has not
been a critical issues for our customer base.
We scale from small footprint singlecore low MB RAM to large
multicore 100GB+ RAM systems. Your code is the same - assuming you wrote
good multicore ready, multithreaded code. Our compiler and runtime and GC
do the rest. You can try out our trial product at www.aicas.com.
Not making a sales pitch here. If you want that, email me.
dbeberman -at- aicas.com
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