Slashdot Mirror
An Interesting Look At the Performance of JavaScript On Mobile Devices
First time accepted submitter faffod writes "Coming from a background of console development, where memory management is a daily concern, I found it interesting that there was any doubt that memory management on a constrained system, like a mobile device, would be a concern. Drew Crawford took the time to document his thoughts, and though there is room for some bikesheding, overall it is spot on. Plus it taught me what bikeshedding means."
Don't blame Timothy for the dupe; no doubt he posted it from his mobile.
But it didn't teach you how to spell it...
At delivering malware payloads even in your adbanners. Yes everyone: The brilliant brainiacs that decided scripting documents was "smart to do" just ends up screwing you over in the end. Especially funny since they had the example of macros in documents (like MS Word ones) beforehand and saw how that ended up working out too in malware galore being delivered via those scriptable documents. Why not open up the door and let the trash come blowing in next! Might as well, since the material you consume comes loaded with it because of this idiot's move.
I'm probably going to get downvoted as troll, but my experiences with most console developers were often strange (as a developer myself).
Talks usually end up in most of them dismissing scripting languages, higher level APIs (such as OpenGL), or certain algorithms as useless because they are slow, use too many instructions unnecessarily, waste cache, etc.
Any attempt to raising a point about how you don't need to optimize everything but only few critical zones of your code (what matters), or that a cache wasting algorithm can end up being faster anyway just because it's more efficient, immediately results in myself being dismissed or treated as ignorant because, something inefficient is obviously inefficient and I must be stupid for not realizing that.
This article reminds me of that. The author claims (in his first claim) that he is determined to prove that something is less useful because it's slower, and nowhere in that huge long piece of text there is anything useful offered as proof, instead he keeps posting data about how slow Javascript really is.
didn't slashdot post an article about the performance of JavaScript on mobile devices last week? just asking
I learned C++ then VB.NET then C# then JavaScript. I was shocked at how "anything goes" it was and I assumed it was a memory nightmare. Considering my i5-2400 sometimes maxes out on pages with complicated javascript, I'm not surprised. I heard that JS can take 10x more memory than it needs at any given time realistically.
The one thing I can't wrap my head around is if it was made a "real" language, would it be a gigantic security disaster? Or could it be limited enough to not turn into Flash, Java, etc?
Whew, I'm glad we managed to get everyone to switch off of memory-leaking and CPU intensive Flash stuff over to standards compliant HTML5 and JavaScript then!
https://en.wikipedia.org/wiki/Parkinson's_law_of_triviality
It gripped her hand gently. 'Regret is for humans,' it said.
Animated GIFs.
I think they're of the devil, but for some reason a lot of baseball stat heads still use them instead of a video format when they want to post a few seconds of a game for illustrative purposes. It's weird because these are generally young guys, not the old farts who you'd expect not to have changed their workflow since 1995...
JavaScript on the iPad? That doesn't seem slow - certainly not enough to where it registers anyway.
#DeleteChrome
I'm old enough to remember the assembly language versus high level language debates. I even remember the augments about virtual memory versus overlays. Why are we retreading the same arguments for fifty years? Note a program that runs slower than desired may still be quite useful; a program that generates incorrect results is worthless perhaps even dangerous.
Coincidentally, most IDEs for javascript have little to no spelling assistance
Spell-check in IDEs generally relies on static analysis of the variables in scope at any given point in the program. The more dynamic a language's type system is, the harder it is to statically find the names of symbols in scope at any given point in the program. PHP and Python are kinda-sorta OK for this because all global variables are out-of-scope (PHP) or read-only (Python) unless declared otherwise at the top of a function's definition (or, in PHP, unless the variable is one of the predefined superglobals, whose names are all uppercase starting with $_). This way, the IDE can parse a function for all variables assigned to in a function and assume they're local. JavaScript, on the other hand, defaults to making all variables global unless declared local with the var keyword.
Spell-check also relies on static knowledge of what source code files are in scope. This is dead easy for Java. In PHP you scan for require_once, and in Python you scan for import, but even then, a module is occasionally conditionally imported, and importing has side effects. JavaScript can't include JavaScript at all except by appending a <script> element to the HTML DOM with the src= attribute referring to the other script, and the idiom for that is harder to recognize than a simple import statement.
It looks like you want to get rid of all JavaScript in web pages. What's a better way to present interactive forms over the Internet that doesn't involve reloading an entire 100 kB page whenever the tiniest bit changes and doesn't involve paying someone to make six different native applications, one for each operating system?
for some reason a lot of baseball stat heads still use [GIF animations] instead of a video format
Some browsers can view only H.264 and animated GIF. Other browsers can view only Theora, WebM, and animated GIF. Some, such as the latest version of Internet Explorer that runs on Windows XP, can't view anything but animated GIF without plug-ins that may or may not be installed and that the current user may or may not have privileges to install. If the only video format supported by all browsers is animated GIF, what should a site use to reach the most viewers?
The author should get a clue.
The real point is that memory allocation is expensive. With a garbage collector freeing memory can be super-expensive too,
But without those super-hyper-unobtainium batteries, memory allocation on mobile devices will always
be a problem. It will chew lots of Joules compared to other operations. Your app will be known as
both slow and a battery waster if you do too much memory allocation.
Don't be an idiot and allocate (and free) an image for every frame of an animation (as it appears the author thinks
is reasonable practice).
Think about what's really going on - don't create new objects all the time. Any reasonable OS has to wipe the
memory it gives you (for security) and then there's the garbage collection issue.
it seems like there could be a pretty simple automated dupe-checker that flags it and tells the editors
It's called the "visited link color" function. Or perhaps not even the editors read the featured article.
I think I had one of those at TGIFridays one time.
Mod me down, my New Earth Global Warmingist friends!
I made a comment to a poster over on the original posting of this. I think it's worth expanding upon in case people are persuaded by the arguments in the paper.
First off, just as TFA predicts, I'm not going to try to conquer his mountain of facts and experts by presenting a mountain of citations. Instead, I'm going to point out where his conclusions are not supported by his facts and point out his straw man arguments and his attempt to convince us through overwhelming expert opinion.
The straw man: In the article, he presents two scenarios (photo editing and video streaming) and claims that you can't reasonably do those because of memory limitations (on the iPhone/iPad). He then concludes you can't produce useful apps because you can't do those two. I couldn't find any citations of people attempting to do this on mobile using JavaScript. Choose the right tool for the job here. I'll give him these two use cases (and several others: 3D Games, audio processing, etc), however to extrapolate from here that no useful apps can be produced (ever!) using JavaScript is a leap too far.
Next, he spends a lot of time diving into the particulars of garbage collection (GC). I'm going to grant him practically every point he made about GCs. They're true. And, it's true that mobile is a constrained environment and you must pay attention to this. But, this is largely known by developers who are trying to write high-performance JavaScript applications on mobile. Hell, -anyone- writing high-performance apps in any language need to be aware of this. If you allocate memory during your animation routines in a game you're asking for trouble, regardless of the language. So, to me, this part is just a call to pay attention to your memory usage in your apps. This is really useful advice and I will be paying even more attention to the new memory tools available in the latest Google Chrome dev tools.
One of the biggest problems in the rant is the comparison of pure computing performance and his claim that ARM will never be as fast as desktop. I'm going to again grant that this is true. However, this means crap-all for most apps. Tell me: How many apps do you have one your phone that are processor bound? None? One? Two? The vast majority of apps spend their time either waiting on the user or, possibly, waiting on the network. You can write a lot of really useful apps even given constrained processor and memory. Anyone remember the Palm Pre? The TouchPad? Most of those apps were JavaScript and they worked just fine.
This brings me to the point of all this, TFA's author focuses on performance. However, users focus on responsiveness. JavaScript is perfectly capable of producing responsive applications. Sometimes, it takes attention to detail. Nothing is ever 100% free and easy. JavaScript is not a magic solution and those of us who think that JavaScript has a future in mobile app development know this. This is why programmers get the big bucks. Writing mobile apps, you need to be aware of the effects of CSS, memory, processor, responsiveness and more.
Author of Enyo: Up and Running from O'Reilly Media
Actually a pretty well written piece, if a bit wordy. I see a lot of people commenting here are perhaps missing the point, thinking that the author's angle was JS=BAD. Not at all. My take was his issue was not so much with JavaScript, but with Garbage Collected languages in general.
An important point he made regarding GC routines and how they tend to be unpredictable in terms of when and how long they run. Also, much was discussed on his observations that, if you have several times more memory available than what your app needs, the GC routines are very non-intrusive. However, when you get into a low memory situation, the performance hit from GC is huge and causes obvious stutters in the application and/or it's UI.
Also, some discussion on the irony of working around (or trying to "spoof") the GC by using various manual techniques, and how that almost amounts to manual memory management. All in all, a really interesting read.
like the author, then people WOULD believe YOU
A page references itself 17 times, with a link to itself each time, and yet is still inscrutable. WTF are they talking about on that page? I want back the 17 seconds I wasted reading the first few paragraphs of that douchery.
It's not the language that's the problem but the monolithic page in which you put all the content. Just cut it up into the static bits and the small dynamic bit. Any other language, whether native, bit code or machine code will require reloading if you put all your content in a single file and you change the file. While you're at it, you might as well put different parts of your page in different files, so you can re-use things like a menu bar, styles, headers and footers for other pages.
I was promised a flying car. Where is my flying car?
I happen to have an average of about 200 tabs open on most of my daily use machines. This tends to eat most of the resources that my machine has, regardless of how modern the machine is. If it's an old clunker, it chokes on less and I generally don't make it that far before I have to kill the browser and restart it. It seems impossible for any OS vendor and any "full featured" web browser to just deal with the limitations of the system and keep the application snappy and usable.
Sure, it is way faster if you load just a few pages, but I just don't close tabs I think I might need later. Bookmarks accumulate so fast and searching them is bothersome, let alone cleaning them out. Regardless of my reasons why I do it, I see a lot of people hit the limitations of the model in which speed is achieved by unlimited resource claiming and not by efficient coding, if it comes to web browsers. The reason that mobile is in the picture is because a mobile device is way less powerful and battery life is much more of a concern than for a desktop or AC powered laptop.
I wish they would test "speed" by simultaneously loading 200 tabs of content-rich web pages on a single core system with 512M ram available to the browser and a slow magnetic media drive (5400rpm laptop drive) for storage. In my opinion, it would be a way more realistic test than just loading a single page, keeping everything in RAM and only looking at methods that will bottle neck at CPU/GPU or memory access. I bet that "speed improvements" in the JS engine would suddenly come from very different optimizations than from the current philosophy and that they would greatly benefit "mobile" too.
I was promised a flying car. Where is my flying car?
Try looking into node.js and see all your fears come true.
I was promised a flying car. Where is my flying car?
True, animated gif is the most widely supported "movie" format if you look at all target platforms. However, there currently is no technology implemented in browsers that will take an animated gif, re-render it into something that can be accelerated by the video card and use that for output. This results in the browser pumping all the frames non-accelerated to the video card. Devices with limited (read, all devices that have more than a few tabs open, or mobile devices) will hit limitations of the hardware pretty fast with this sort of animation.
I was promised a flying car. Where is my flying car?
Next, he'll expect you to read the 10,000 word article!
The very same blog post was already the subject of an article on Slashdot last week. What is going on here ??
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
Opera browser (versions up to 12) was shown on one graph (iphone 4S) in the article and it kicked some serious a$$ but never mentioned again.
One reply to the article was about Opera being only browser to run Google Wave, kind of... "The only browser that ran it with anything resembling
“speed” for it’s first year or so was Opera, and Opera never really worked very well with it anyway."
I enjoy security through obscurity but Opera is just too good a browser to ignore.
What in Sam Hill does that mean?
Dont force a single 100kB monster to begin with, doh.
Say a Slashdot story has 100 comments, and each comment is 1 kB. How should these comments be sent to the browser?
Break the monster down into bytesized chunks
Without JavaScript, you can't use AJAX, and without AJAX, you can't retrieve comments incrementally as the user requests them and add them to the page. Or are you talking about displaying one comment on each page the way certain mailing list archives do?
I am a C++ developer for more than 16 years now and I did some Java and C# development in the past. Based on that experience, I can fully attest the correctness of the reasoning presented in the article. In addition, I am aware of the fact that practical (as opposed to theoretical) C and C++ programs are chock-full of security issues, most of which can be attributed to the lack of type safety in C and C++.
Being an engineer, I started to develop a "fix" for the deficiencies of C and C++, but at the same time tried to retain all the good aspects such as stack allocation, value arrays and so on. The language is called Sappeur (from Sapeurs-Pompiers, french for Firebrigade-Member (which I once was)) and technically is a compiler that translates into Posix-compliant (pthreads) C++ code. That means it should compile into binaries on all major platforms from phones to mainframes.
Here it is:
Disclaimer: Yes, the current compiler version definitely is not polished, it probably is in some ways a quick hack, but if you work around the quirks, I am quite positive it can provide real value relative to Java (more efficient, better resposniveness, smaller memory footprint) and relative to C or C++ (more secure).
Especially when you read things like this
I get no ads or malscripted content via this creation of mine:
APK Hosts File Engine 9.0++ 32/64-bit:
http://start64.com/index.php?option=com_content&view=article&id=5851:apk-hosts-file-engine-64bit-version&catid=26:64bit-security-software&Itemid=74
I get NO malware/malscripted pages (redirects or otherwise) malware because of it.
(They are dangerous -> http://techtalk.pcpitstop.com/2013/06/26/malware-more-likely-to-come-from-legitimate-sites/?know-notenough= if that source isn't enough I can provide CISCO stating the same)
Most are Dynamic DNS + FastFlux based botnet attacks & are host-domain based (hard to kill vs. IP address based ones & it is the predominant design for malware/botnets).
I operate @ the IP stack level via tcpip.sys since hosts is a filter for it in Ring 0/RPL 0/kernelmode far before (& faster than) browser addons in Ring 3/RPL 3/usermode (which slow down usermode browsers even more - fact).
Complaint to /.: Can't post more than 2 links due to the "lameness filter" on posts (which is lame in & of itself when it suppresses vaild information).
Anyhow/anyways: FireFox users have NoScript - use it!
I use Opera 12.16 64-bit & set its GLOBAL site preference default to NO javascript, plugins, cookies, frames/iframes - in essence, things that get actively exploited maliciously (and then IF needed for full function on a site, then, as an "exception site"? I turn it on ONLY for that site only (think ecommerce or online banking etc.)).
Combining hosts & no javascript works (on smartphones since they have a bsd ip stack)!
APK
P.S.=> I also surf far, Far, FAR faster too not seeing adbanners or processing javascript - in fact, if you take a look @ the list of enumerated benefits it yields in added speed, security, reliability (vs. DNS faults especially) & even anonymity to an extent? You'll understand WHY I created it + made it freely available to others also - necessity WAS "the mother of that invention"... apk
Bottom line: just because you're using a GC'd language and you CAN ignore memory management, doesn't mean you SHOULD. That goes for JS, Java or any other GC'd language in existence.
I hate to go off on a tangent... but that won't stop me from doing so, because I think it's actually the core of the issue and is entirely non-technical:
This all goes back to the abysmal state of many (most?) "modern" developers.
If you grew you with computers at the time I did, the late 70's/early 80's, and you learned to program those early 8-bit home computers, you kinda take this stuff for granted (memory management I mean). You just inherently think differently than "modern" developers do. You see things at a much lower level... even when you're working at a high level of abstraction, your mind automatically goes lower... instantiating an object in Java? You're mind at some level is thinking about how memory is being allocated, how the object reference is being stored, etc. Hell, you even start to think about the messages the OS is passing around, how those messages must map to C functions, and how those functions ultimately resolve down to assembly.
I'm NOT saying you KNOW all those details... not really... you just know the concepts... and I'm certainly not saying such details are relevant most of the time because they're not... I'm just saying that's the way our brains work... we can "see" all the levels below the one we're actually working on in our minds' eye, if only in a conceptual sense, and it happens without trying.
I's because we generally started learning at those low levels and everything over the years has built up logically from there. Most of us started with BASIC but quickly jump to Assembly because that was the only way to achieve what we really wanted to (games, mostly). Once you're at that level, it's an entirely different mindset. Those of us that also had an electronics background go a step further because we even go below the Assembly level sometimes (and that wasn't all that uncommon back then... of course, the electronics were considerably simpler and easier to understand than they are now).
That's a VERY different evolution than the kid that STARTS with Java or JavaScript or whatever now, then goes to school and learns more high-level stuff. And it shows in daily work life all the time! I see people constantly in my career who aren't really bad developers, but they are, somehow, lacking... it usually shows when things aren't working as expected. They have a difficult time breaking things down and figuring out what's going on. Oh, they can Google an answer as well as anyone, and hey, probably 9 times out of 10 that's sufficient. But they're just stumped beyond belief that one time... they just can't get into the details and work the problem at a fundamental level. They don't REALLY understand how these machines, these operating systems, work. And that's a really bad state of affairs.
(to be fair, some of us that learned in the "ground-up" way sometimes have difficulty STAYING at a high level... we sometimes trip over discussions that are too abstract because our brains are searching for the details that aren't there, and really aren't even relevant... that's a whole other discussion, but it's a true phenomenon).
All of this... to try and pull it back to topic relevance... means that relatively simple things like designing your code to minimize object allocation and deallocation seems mysterious to a lot of modern developers... they don't always get why it's important, and it seems like some black art or something even when they do... to us old-schoolers, I guess that's what we are now, it's actually quite natural to think that way. Even in JavaScript, where I've done considerable work, and highly complex work, GC has never presented a big issue for me, primarily because I've ALWAYS thought about it and know how to avoid it at the right times. The language itself isn't flawed, modern developers' ability to use it effectively is.
We're proba
If a pion (n-) collides with a proton in the woods & noone is there to hear it, does lamdba decay into the source pa
Yes, <iframe> was proposed as an alternative to AJAX. But years ago, hundreds of iframes on a page would cause certain browsers to crash. And even in 2013, the test case from that bug still causes Chrome to show an unresponsive tab alert on my laptop. Besides, putting each comment in its own iframe doesn't support batching. Unlike JavaScript, which can request multiple comments as a single JSON or XML object, each iframe needs its own HTTP request.
1) Benchmarks are useless for a device OS that only allow one browser rendering engine. It prevents apples-to-apples comparisons of rendering engines on the same hardware, so there's less incentive for them to improve their browser.
2) Any application for iOS that uses PhoneGap or a similar Web-based application framework is basically being shot in the kneecaps by Apple applications policy. Apps can't use Nitro, and they can't use other JavaScript engines with JIT compilation. It wouldn't surprise me if Firefox OS apps can run circles around nearly identical iOS apps made with PhoneGap on comparable hardware.
GC is memory-hungry, but memory is scarce on mobiles => forget about GC.
"He said (and I agree) that the problem is NOT ads." - by Arker (91948) on Monday July 15, 2013 @11:09AM (#44284689) Homepage
Malware More Likely to Come From Legitimate Sites:
http://techtalk.pcpitstop.com/2013/06/26/malware-more-likely-to-come-from-legitimate-sites/?know-notenough=
and
More dangerous to click on an online advertisement than an adult content site these days, Cisco said:
http://www.securityweek.com/easier-get-infected-malware-good-sites-shady-sites-cisco-says
APK
P.S.=> You need to be better informed - take a read up in those 2 links above, in order to be... apk
"How much memory is available on iOS? It’s hard to say exactly."
Exactly. Because it's an appliance. And you're either willing to take it apart and learn how it works so you can make it do what's needed, or you accept that you're an appliance operator and stop bitching about it.
"You must try to forget all you have learned. You must begin to dream." -- Sherwood Anderson
Well, the proof's in the pudding on malware in ad banners online AND in speed/bandwidth they consume on users too (that they pay for out-of-pocket).
* You don't have to repeat it - you have to face up to it: I merely posted undeniable, verifiable facts in that regard earlier!
(That adbanners have been shown by reputable sources as housing malware AND on regular sites (not just "Pr0n" sites etc./et al)).
APK
P.S.=> So this is yet another consideration to take on adbanners NOT doing users a favor in adbanners being speed/bandwidth hogs taking away what users pay for out-of-pocket that adbanners consume(ontop of them housing malware/malscripting)... apk
I'm sorry but when his relatively simple content-page loaded like it did I looked at his HTML. Drew Crawford isn't anal enough to be taken seriously on performance and he's using something that spits some 40 odd script tags on the page for one purpose that puts some teeth in my straw man.