Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

An Interesting Look At the Performance of JavaScript On Mobile Devices

timothy posted 1 year,16 days | from the down-in-the-weeds dept.

Cellphones 157

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

cancel ×

157 comments

Sorry! There are no comments related to the filter you selected.

Bikeshedding (-1)

Anonymous Coward | 1 year,16 days | (#44280683)

Is that like a Cleveland steamer?

Re:Bikeshedding (1)

binarylarry (1338699) | 1 year,16 days | (#44281299)

I think I had one of those at TGIFridays one time.

Mobile web really IS slow! (5, Funny)

EvanED (569694) | 1 year,16 days | (#44280687)

Don't blame Timothy for the dupe [slashdot.org] ; no doubt he posted it from his mobile.

Re:Mobile web really IS slow! (2)

faffod (905810) | 1 year,16 days | (#44280701)

Sigh... I did look back to see if it had been posted, didn't go far enough. *hangs head in shame*

Re:Mobile web really IS slow! (1)

EvanED (569694) | 1 year,16 days | (#44280733)

Heh, no worries. It's mostly the editor's job anyway...

Re:Mobile web really IS slow! (4, Insightful)

Trepidity (597) | 1 year,16 days | (#44280783)

Since this was literally the same link, not just the same story but via a different source, it seems like there could be a pretty simple automated dupe-checker that flags it and tells the editors: a story with the same link was posted in the past N weeks, are you sure you want to post?

Re:Mobile web really IS slow! (2)

Mitchell314 (1576581) | 1 year,16 days | (#44280843)

I'm surprised I haven't seen anybody publish a script that sees if something similar has been posted in the recent past on slashdot based on key words or some analytics voodoo. Would make for an interesting project, and fitting too!

Re:Mobile web really IS slow! (1)

Anonymous Coward | 1 year,16 days | (#44280867)

slashdot is too static for that. reddit, which provides a json interface with several frameworks already established, makes a much better research platform.

The editors don't RTFA (4, Funny)

tepples (727027) | 1 year,16 days | (#44281191)

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.

Re:The editors don't RTFA (2, Informative)

Anonymous Coward | 1 year,15 days | (#44282235)

- Is there only one editor, who always reads every single featured article?
- Are slashdot editors barred from clearing their browser histories?

Re:The editors don't RTFA (2)

tepples (727027) | 1 year,15 days | (#44283523)

Is there only one editor, who always reads every single featured article?

Ideally, the buck is supposed to stop with an editor-in-chief.

Re:The editors don't RTFA (0)

Anonymous Coward | 1 year,15 days | (#44283311)

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 always thought the "f" stood for a different word.

Re:Mobile web really IS slow! (5, Funny)

phantomfive (622387) | 1 year,16 days | (#44281045)

Quick! Now's your chance! Go copy a high-rated comment from the other story and get yourself a +5 moderation!

Re:Mobile web really IS slow! (4, Funny)

phantomfive (622387) | 1 year,16 days | (#44281619)

For a real salute to recursion, I personally copied that comment from a previous dupe......

Chek your speling (4, Funny)

Rob_Bryerton (606093) | 1 year,16 days | (#44280719)

From TFS:

...and though there is room for some bikesheding, overall it is spot on. Plus it taught me what bikeshedding means."

But it didn't teach you how to spell it...

Re:Chek your speling (3, Funny)

Anonymous Coward | 1 year,16 days | (#44280751)

<Ralphie Wiggam> The missing 'D' was used for my grade. </Ralphie Wiggam>

Re:Chek your speling (2)

slashmydots (2189826) | 1 year,16 days | (#44280985)

Spelling isn't important in programming, lol. That's what the IDE is for. Coincidentally, most IDEs for javascript have little to no spelling assistance, lol.

Re:Chek your speling (2)

arth1 (260657) | 1 year,16 days | (#44281109)

I'm glad I don't work with you, if you laugh at loud for every sentence you write.

Re:Chek your speling (0)

Anonymous Coward | 1 year,16 days | (#44281321)

me too lol!!!1!!!!111!!!

Re:Chek your speling (0)

Anonymous Coward | 1 year,16 days | (#44281343)

LAL!. Chuckle when someone raises their voice?

Re:Chek your speling (2)

lxs (131946) | 1 year,15 days | (#44282173)

I like the comma before "lol." Write sentence, little pause, bellylaugh. Classic.

Re:Chek your speling (1, Offtopic)

slashmydots (2189826) | 1 year,15 days | (#44283433)

You should be. Since I'm the IT manager, I'd fire you with an attitude like that.

Spell-check in IDEs (4, Informative)

tepples (727027) | 1 year,16 days | (#44281131)

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.

Re:Chek your speling (2)

GigaplexNZ (1233886) | 1 year,15 days | (#44282155)

Spelling isn't important in programming, lol. That's what the IDE is for. Coincidentally, most IDEs for javascript have little to no spelling assistance, lol.

Tell that to Microsoft who had to break compatibility [microsoft.com] due to some spelling mistakes. Specifically, the MFC/ATL section.

Re:Chek your speling (2)

MrBandersnatch (544818) | 1 year,15 days | (#44282353)

"Spelling isn't important when writing. Thats what the word processor is for!"....."lol"

You're me at 13 aren't you? :)

Re:Chek your speling (1)

slashmydots (2189826) | 1 year,15 days | (#44283445)

Is this your first time on the internet?

Re:Chek your speling (0)

Anonymous Coward | 1 year,15 days | (#44281949)

looks like a typographical error, not a spelling error

Re:Chek your speling (1)

Flere Imsaho (786612) | 1 year,15 days | (#44282161)

Irony overload, abort, abort!

Words that should never be included in headlines (-1)

Anonymous Coward | 1 year,16 days | (#44280723)

Number 107: "Interesting". Any story that has to headline itself "interesting" is vanishingly unlikely to be worth the time to read.

It is performing excellently (0)

Anonymous Coward | 1 year,16 days | (#44280863)

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.

What's better than JS? (2)

tepples (727027) | 1 year,16 days | (#44281151)

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?

Re:What's better than JS? (4, Interesting)

Arker (91948) | 1 year,16 days | (#44281475)

I am not the GP but I sympathise with his comment.

"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?"

Dont force a single 100kB monster to begin with, doh. Break the monster down into bytesized chunks and this suddenly doesnt look so impossible to do in straight html, now does it? You can even keep your 100kB script as well if you want, but you must put a link to the straight version in the noscript tags at the very least. (Personally I urge you to give me an option to use the straight version even in a scriptless browser, otherwise you will probably force me to disable all scripts on your site, but it's not a formal requirement like the noscript tag.)

From day one that was the way you were supposed to do it when you added scripts to your web pages, and it's not that I want to remove all scripts from the web, I want to remove this idiotic assumption it's ok to skip the webpage, hand out a script instead, and pretend all is well. It isnt. Javascript is fine for making a fancier version of a webpage (but only as long as you dont use it as an excuse to skip the simple version.) But scriptless browsers are an integral part of the web as long as it's existed and they arent going away. If you dont support them you arent supporting the web and are missing the point of the web.

With the current threats and trends in malware, you're likely to see only more and more scriptless browsers. Browsers that support scripts just fine are being told not to support YOUR scripts - at least not until you are trusted. Making a good first impression more and more means making a good first impression WITHOUT grabbing your ecmascript crutches, without just ASSUMING that the visitor is immediately comfortable enough with you to be touched in that way.

Even if you cant figure out how to write a webpage or hire someone that knows, you should not need to pay for 6 different native apps - unless your app has a really niche market at least. Just get it written once in a high level language, release it GPL so that anyone interested in porting it to a new platform can. You'll likely have ports contributed back faster than you can pick out the right guy internally to receive them. (This part assumes your app does something that a computer literate person might find useful, of course, it strikes me that is a blind assumption though.)

Dont tell me your afraid to release your precious source - you're doing that right now every time your server sends out 100kB of ecmascript already.

Re:What's better than JS? (3, Informative)

foniksonik (573572) | 1 year,16 days | (#44281843)

Sorry. Things change. It won't be long before browsers are just wrappers around the JSVM and all web addresses are just sandboxed applications running in it. The web is the biggest App Store there is.

You want raw data in a structured format? There are REST APIs for that, they return JSON. HTML is too verbose by far as the default response and is useless for any other client besides an HTML renderer.

Text content is moving to Markdown as a standard as well. It's quicker and easier and covers text formatting. Clients should just render it directly.

I could go on but it's probably lost on you. Suffice to say that modern server app development is evolving to be service driven and client agnostic. HTML is one of many targets. Why write server apps or content engines (CMS/blog/forum) for a single client when you can instead create a server based API and several thin client apps (JS, DART, iOS, Android, C++, .Net, Lua, etc).

Re:What's better than JS? (1)

Anonymous Coward | 1 year,15 days | (#44282129)

> Sorry. Things change. It won't be long before browsers are just wrappers around the JSVM and all web addresses are just sandboxed applications running in it. The web is the biggest App Store there is.

Not my Web. Most Slashdot ads are lost on me because of that. Heck: I'd even *read* an interesting ad or (gasp!) click on it. But: no Javascript => no ads? Too bad, so sad.

> Text content is moving to Markdown as a standard as well. It's quicker and easier and covers text formatting. Clients should just render it directly.

Yeah, great: I'd take Markdown any day (I'd probably prefer *that* to the ugly hack HTML is anyway -- at least when some form of stylesheet for this is agreed upon). It's the mixing up of documents and active content I detest with passion. I'm browsing the internet to *read* something, not to have *your crappy code* executed on my computer without being asked. Politely.

Re:What's better than JS? (1)

foniksonik (573572) | 1 year,15 days | (#44283053)

So your big complaint is ads? You do know they are inevitable regardless of the tech employed. If HTML had never become the standard and everything was written in C++ you would still get ads. Look at iOS and Android apps. Look at the latest Ubuntu search (and Windows now too). There are ad supported (and malware linking) apps all over. It's even worse as they have less sandboxing and can cause more problems.

Re:What's better than JS? (0)

Anonymous Coward | 1 year,15 days | (#44283517)

Sorry, but I'm not going to bother with that. Non-interactive (ie: static) websites suck, and the only reason they exist in the first place is for legacy reasons: there was a time when it wasn't possible to do anything more, and then even when there was you couldn't count on most people to have support for the dynamic feature set. But that time is LONG past (except for the minuscule handful of people who cling desperately to the past). Now, pretty much everyone has access to those features, and I've got a lot of shit to do, so I'm not about to double my work by having to maintain separate static and dynamic codebases for the benefit of WAY less than 1% of users. I have better things to spend my time on.

Did you mean one comment at a time? (1)

tepples (727027) | 1 year,15 days | (#44283595)

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?

Re:What's better than JS? (0)

Anonymous Coward | 1 year,16 days | (#44281495)

A standardized (or at least, well-documented) protocol that anyone who cares can use to implement their own user interfaces (which, history shows, people will do if the service is a useful one.)

Re:What's better than JS? (1)

tepples (727027) | 1 year,15 days | (#44283635)

A standardized (or at least, well-documented) protocol that anyone who cares can use to implement their own user interfaces

The protocol that the world appears to have standardized on for this purpose consists of HTTP, HTML, CSS, and JavaScript. Yet certain people continue with the phobia of JavaScript.

It's not the language that's the problem (1)

dutchwhizzman (817898) | 1 year,16 days | (#44281823)

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.

Re:What's better than JS? (2)

evilviper (135110) | 1 year,15 days | (#44282333)

It looks like you want to get rid of all JavaScript in web pages.

He doesn't, but he makes a good point that "2%" performance isn't good enough, and you should avoid javascript if you can.

I consider this most important for projects like Firefox OS, which are pushing a platform for slow, mobile devices, where Javascript is the only programming language available.

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

In my extensive experience, reloading the page every time is actually still FASTER and makes for a more responsive experience. Compare gmail with JS or in classic mode... Classic mode isn't as shiny, but it sure moves a lot faster. Or look at Netflix's queue... Insane delays from clicking the "move to top" arrow, until it actually happens, or the delete button, while reloading the page on each button press would happen in a fraction the time, and would work far better on low-end devices (and they wouldn't need a super-crippled "mobile" version of their site).

A tiny bit more load on your server, in exchange for a much more responsive client-side experience. A bit more bandwidth usage, but compression and caching of all other page elements should make it pretty insignificant.

Re:What's better than JS? (1)

tepples (727027) | 1 year,15 days | (#44283703)

In my extensive experience, reloading the page every time is actually still FASTER and makes for a more responsive experience.

I agree with you that some sites using AJAX are poorly designed. I disagree that sites using AJAX must necessarily be slower than reloading the whole page for every little piddly action. Say you've landed on an article with 100 comments in the discussion section. Every time you expand or collapse a thread, the article and all 100 comments reload. Every time you begin, preview, or submit a comment, the article and all 100 comments reload. I don't see how that'd be so convenient for people on slow and/or metered Internet connections.

Typical console developer rant, IMO. (3, Interesting)

goruka (1721094) | 1 year,16 days | (#44280915)

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.

Re:Typical console developer rant, IMO. (-1)

Anonymous Coward | 1 year,16 days | (#44280959)

For fuck's sake, it's not downvoting, it's called being modded down. Go back to reddit, hipster.

MOD PARENT UP (-1)

Anonymous Coward | 1 year,16 days | (#44281267)

Unless you're a douchebag reddit hipster with mod points, in which case go back to reddit.

Re:Typical console developer rant, IMO. (0)

Anonymous Coward | 1 year,16 days | (#44281005)

It comes from a usability standpoint. I've developed the same application in Javascript, Java, and C. Basically, it took ten events and determined the length of time SINCE and length of time UNTIL those events, broken down into months, days, weeks, years, hours, min, sec, in a way that would say, "It has been X years, X months, X days, X hours, X min, X seconds since..."

Javascript was the slowest.
Java came in 2nd.
C came in first.

I program in many different languages (I'm not biased to either one). I will tell you this, though: Use the language that's best for the job. If Javascript is slow THAT mobile application, then, guess what? Program it in a translated language. IF that is slow, too; then hey, try Native. If that's slow, shit, son, you've got some work to do.

Re:Typical console developer rant, IMO. (2)

Anonymous Brave Guy (457657) | 1 year,16 days | (#44281051)

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) ... immediately results in myself being dismissed or treated as ignorant

To be fair, if you were debating with someone who writes applications that really do need the very top levels of performance, and you claimed that optimising trouble-spots would be sufficient to achieve that, then you were ignorant. For most software, being within a factor of 2 or 3 of hand-optimised low-level code is easily sufficient, and a bit of work with the profiler to identify the most serious flaws will go a long way. The rules change when you shift from that kind of performance standard to needing the very top levels, because then the emphasis on speed permeates everything.

Re:Typical console developer rant, IMO. (1)

OneAhead (1495535) | 1 year,16 days | (#44281103)

Ahh, the quest for Uniformly Slow Code [c2.com] . Something the scientific programmer is deeply familiar with. Too bad there's so few people who understand.

17 (0)

Anonymous Coward | 1 year,16 days | (#44281633)

A page references itself 17 times, with a link to itself each time [uniformlyu...ebpage.com] , 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.

Re:17 (1)

OneAhead (1495535) | 1 year,16 days | (#44281665)

Whine me a river. I wish I would have found a better reference for that concept, but I don't have all day. Since you already wasted 17 seconds on it, feel free to double down and google up a better reference and post it here.

Re:Typical console developer rant, IMO. (1)

radarskiy (2874255) | 1 year,16 days | (#44281149)

There is no one so precious that they have slipped the surly bonds of Amdahl's Law.

Re:Typical console developer rant, IMO. (2)

Arker (91948) | 1 year,16 days | (#44281107)

They arent useless but they are certainly not always the best (or even simply an appropriate) tool to use. Scripting is great for the trivial-but-useful, particularly a one-off or a mock-up. But any sort of serious computer program is going to be better if you program it and most anything that is trivial-but-useful enough to have a jscript app should be quickly reproducable on any platform that you want in a native fashion. Do you need a native program to have a simple calculator? No, javascript will do. And that's great.

At the same time, if that simple calculator is something you use very often, make an app. You dont have to be worried about the simple calculator overwhelming your phone to think that makes sense - because we all multitask these days and/or worry about electricity/battery life etc. on many devices.

It's funny seeing how people are rediscovering the importance of programming as a result of these phones. The reason it makes me chuckle is that I remember working with PCs that had orders of magnitude less system resources than these phones do, so I understand that it is actually the abstraction layers in use that make the hardware seem so limited.

You kids nowadays think a power-throttled ARM processor and a couple gigabytes of RAM is 'limited resources.' You should try a z80 with 8kb ram. Believe it or not, if you actually program the thing instead of expecting your libraries and abstraction layers to deal with it for you, you could make that work too.

Re:Typical console developer rant, IMO. (1)

Kartu (1490911) | 1 year,16 days | (#44281447)

Does "World of Warcraft", the most popular (western) MMORP with (once, and probably still) 10+ million users sound like a program serious enough?
Guess what, its UI is scripted (LUA).

Scripted languages have enormous advantage of being much easier to bugfix than native apps.

Re:Typical console developer rant, IMO. (1)

Arker (91948) | 1 year,16 days | (#44281559)

Whee, the UI of a game is scripted. That's not exactly a critical application, and it's not like they tried to write the whole thing in ecmascript. And it's not like the gamer market hasnt been well traind to accept and even expect to constantly buy more powerful hardware in order to 'consume' a never-ending string of bugfixes from game launch date to EOL.. Anyone that sets anything up so that his game UI crashing or malfunctioning in strange or unforseen ways is a big problem is an idiot.

"Scripted languages have enormous advantage of being much easier to bugfix than native apps."

This is a strange statement to make. They do avoid certain types of bugs by not giving you enough control to introduce them, of course. But when you hit a bug it's more likely to be a bug in your environment (beyond your control) that you cannot fix. Other than that, what? A shorter text to sort through finding the bug I guess. A molehill beside mountains, in the wrong application.

Re:Typical console developer rant, IMO. (1)

faffod (905810) | 1 year,16 days | (#44281639)

WOW is a serious project, no denying it. But if it doesn't perform sufficiently, the user is expected to purchase better hardware. On a console or mobile, that is not an option, the hardware is fixed. If two developers make the exact same game, and one uses a native language with few libraries, and the other uses an interpreted library with highly abstracted libraries, the experience provided to the end user will not be equal. You can profile the interpreted code to death and still never achieve the fidelity and quality of the native solution. You'll have noticeably fewer polygons, fewer AI, etc. Now maybe the spec for the game you're making will still be met, in which case knock yourself out. But In choosing that path you have already locked in an upper bound.

I have used Lua in a variety of console games that I have shipped, and it has its uses. In particular, iteration time with an interpreted language is typically much faster. When trying to hone the experience, iteration rules, and the developers that allow their content creators to iterate quickly and effortlessly will always be able to produce a game that feels more polished. It is a case of knowing why you are making your choices, not a case of allowing dogma (only low level is fast) or ignorance (ease of development can overcome inherent limitations). Note, I think that WOW uses Lua because it is easy for the servers to modify the code by sending data packages (but that may just be my male answer syndrome kicking in)

I disagree with the sentiment that scripted languages are easier to debug. I've shipped games where there was no Lua debugger for the designers (yes, that is abusive, and I still apologize to them today, but that was the hand we were dealt). The fast iteration time might make you think that you can keep trying different solutions as a method of debugging. Where the rapid iteration is great for improving the experience, it is a poor approach to take for debugging. Too many developers take the shot gun approach to debugging (and this has nothing to do with interpreted vs compiled, I've seen it everywhere). Though a bit too extreme to be realistic, I like to make people think about this: Debuggers are the worst tool for development, it makes programmers not think and analyze their code and therefore they don't understand it. Once again, between the two is right balance, use your debugger but think about your code - and that has nothing to do with scripting languages.

Re:Typical console developer rant, IMO. (1)

byrtolet (1353359) | 1 year,15 days | (#44282159)

Debuggers are the worst tool for development, it makes programmers not think and analyze their code and therefore they don't understand it.

Very well said.

Re:Typical console developer rant, IMO. (5, Insightful)

arth1 (260657) | 1 year,16 days | (#44281125)

The problem is that your baby is not the only thing running on the system. When you waste resources, you do it on behalf of everything else that runs too. Even if your baby isn't doing anything critical when you waste it.

It only takes one selfish programmer to screw up an embedded system. You are he.

Re:Typical console developer rant, IMO. (0)

Anonymous Coward | 1 year,15 days | (#44282417)

Uuum, NO?
Your "argument" actually is completely unrelated to everything.

His point was, that there is no point in optimizing the code that barely takes any resources to begin with. By definition even. There already is no wasting.

What else runs on the system doesn't matter for that to be true.

And you're a dick.
I recommend get ting an light ened [xkcd.com] . Or Jeff an heavy ened. ;)

Re:Typical console developer rant, IMO. (1)

arth1 (260657) | 1 year,15 days | (#44283127)

Re-read his second paragraph, AC.
Or did you just intend to troll and see how many moderators you could trick?

Re:Typical console developer rant, IMO. (0)

Anonymous Coward | 1 year,15 days | (#44283761)

Aaah, ignorance, delusion and personal attacks.
The last weapons of those with no arguments.

I actually wonder if you read AC's comment at all...
I ask you one single question: What wasting?

Re:Typical console developer rant, IMO. (1)

skids (119237) | 1 year,15 days | (#44283801)

His point was, that there is no point in optimizing the code that barely takes any resources to begin with.

Actually his point is usually applied to a concept of "hot path" where, regardless of how many resources a peice of code "takes", what matters is how often that peice of code is run. The problem with doing this is that programs and their usage patterns change and evolve over time. What was not a "hot path" yesterday can become one due to changes outside the program itself -- e.g. suddenly all the packets it receives have an option set that was only set on 1% of packets when the code was initially profiled.

So you end up with code that can break into being slow, rather than being obviously broken. This increases your workload supporting the program post-release. You have to replicate what customers are doing (good luck) and re-profile while under that particular load to find the new hot paths. So while scripting languages are hailed for ease of development, ease of maintenance in a high performance environment is another matter entirely. If you optimize more things to start out with, you don't end up with this explosion of performance test cases to check.

Re:Typical console developer rant, IMO. (1)

goruka (1721094) | 1 year,15 days | (#44283163)

It only takes one selfish programmer to screw up an embedded system. You are he.

Even though it's unrelated with my original post, you are saying that not going native is worse because it uses more CPU cycles/battery?
Explain to me why, for decades, the industry used J2ME, Java (Android) and now ObjC (Apple). I guess the entire mobile industry is selfish and greedy?
You probably didn't understand GP, though, the message is that you don't need to optimize something that doesn't consume enough cycles be a performance problem.

Not just console (1)

dutchwhizzman (817898) | 1 year,16 days | (#44281865)

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.

Re:Not just console (1)

CadentOrange (2429626) | 1 year,15 days | (#44282257)

How do you manage 200 tabs open at the same time? How do you easily get to the tab you want?

Re:Not just console (0)

Anonymous Coward | 1 year,15 days | (#44282853)

I use it the same way as the grandparent. Answer in short: Either remember the location and cycle or search again.

Now a little inside look about the googling process:
I usually search for answers, so couple of google icons might mark the beginning of new topic followed by results which looked like they might help. Often searching takes a few iterations, first you google whatever you started looking for. Then you likely find the correct term (or just the widely used one) and you search again and might get a pile of better answers. With unknown field it often takes many iterations.
When I find a good enough answer, I usually just jump to the next topic. When I didn't find a good one, I will either go to the other round with the opened tabs (closing them one by one, leaving open only these which might give a clue). Now I will likely only have 5 tabs per that topic (one or two google searches followed by best hits). Most tabs are left open when I actually find successful answers and just move on. Now when I want to go back to some previous tab I just cycle through them (and again closing any tab that has lost it's relevancy).

Re:Not just console (0)

Anonymous Coward | 1 year,15 days | (#44282809)

I close my Firefox when I run out of memory. After restart it reloads only these pages which I am actually looking at. That change is pretty recent, not older than two years, before that it loaded all tabs at once when "Restoring session", it was horrible.

BTW, my "record" is 180 tabs in one tabgroup (I use TabGroupManager extension), other tabgroups were close to empty at that time.

Re:Typical console developer rant, IMO. (1)

White Flame (1074973) | 1 year,15 days | (#44282685)

The funny thing is that he's recommending Automatic Reference Counting instead, which destroys cache much more than GC during regular processing.

thanks for sharing the link (0)

Anonymous Coward | 1 year,16 days | (#44280937)

didn't slashdot post an article about the performance of JavaScript on mobile devices last week? just asking

Obvious (1)

slashmydots (2189826) | 1 year,16 days | (#44280981)

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?

Re:Obvious (1)

Rockoon (1252108) | 1 year,16 days | (#44281403)

I started programming at a time when GOTO was still considered "kosher" (in C, no less) as a lot of algorithms were designed as state machines. To this day I still sometimes consider a goto, but even I stand in awe of the complete retardedness that is javascript.

What happened to languages that pick some things and then do them well? JavaScript seems to have evolved to try to do everything, and yet it doesnt do anything even close to well at all.

node.js (5, Funny)

dutchwhizzman (817898) | 1 year,16 days | (#44281873)

Try looking into node.js and see all your fears come true.

Crisis Averted! (4, Insightful)

GreyLurk (35139) | 1 year,16 days | (#44281021)

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!

Re:Crisis Averted! (0)

Anonymous Coward | 1 year,16 days | (#44281273)

Next stop: all images in SVG.

Re:Crisis Averted! (0)

Anonymous Coward | 1 year,15 days | (#44282405)

That's always been the problem with HTML5, yes we're moving towards more standardisation, but the problem is, the standard is fucking shit.

Standardising around shit never seemed that smart an idea to me.

Re:Crisis Averted! (0)

Anonymous Coward | 1 year,15 days | (#44282427)

Flash was beheaded for being a property closed source solution in an open web.
Javascript is your proverbial polished turd. Literally, a weekend project for it's designer (took about 10 day to design and implement!), Javascript is just a mistake.
It's useful for one, and one thing only: Sliding menus and videos. Nothing more. And this is only the absence of an actually good solution.

Besides, why would you want to run applications in your browser even if performance was perfect? If your window management is really that bad, or your system lacks any and all means of securely sandboxing a running app, maybe you should just fix that? Why would you want to do a whole interpreter and a vm inside the browser - a program designed to download and display HTML documents? It's all just very very silly.

Bikeshedding = Slashdot (2)

Flere Imsaho (786612) | 1 year,16 days | (#44281065)

Re:Bikeshedding = Slashdot (0)

Anonymous Coward | 1 year,16 days | (#44281143)

Slashdot is often the opposite of bikeshedding. People here think they're smart enough to understand things they actually know nothing about, so half the words here are about extremely complex things (e.g., the climate system, the economy) being mis-analyzed by unqualified people.

One thing that's horribly slow on my iPad (1)

93 Escort Wagon (326346) | 1 year,16 days | (#44281071)

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.

Supported by more browsers (1)

tepples (727027) | 1 year,16 days | (#44281183)

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?

but it's slow (1)

dutchwhizzman (817898) | 1 year,15 days | (#44281879)

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.

Repeating the obvious (0)

Anonymous Coward | 1 year,16 days | (#44281101)

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.

Misses the point (0)

Anonymous Coward | 1 year,16 days | (#44281189)

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.

Re:Misses the point (-1)

Anonymous Coward | 1 year,16 days | (#44281329)

That's real retarded, sir. That's real retarded to do that, sir. Now stop trying to convince us that you are anything but a creepy ass cracker, and say something smart. Something that a proper nigger gentleman would say.

More Full Response (4, Insightful)

El Royo (907295) | 1 year,16 days | (#44281309)

I made a comment [slashdot.org] 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.

Re:More Full Response (1)

Anonymous Coward | 1 year,16 days | (#44281391)

> TFA's author focuses on performance. However, users focus on responsiveness.

A very over looked point when it comes to the technical design of UI. User's perception of performance is not the same as the actual performance and in a UI you have to balance between the two.

maybe if you bolded every other sentence (0)

Anonymous Coward | 1 year,16 days | (#44281545)

like the author, then people WOULD believe YOU

Re:More Full Response (1)

Anonymous Coward | 1 year,15 days | (#44282105)

I can give you an example of it. Me. A recent. Client wants a photo editing app for ALL of the mobiles, so I produce an IOS quote and a slightly larger Droid quote (Android tends to have slightly more longer dev times due to all the bloody handset incompatibilities I need to test for especially when doing hardware stuff (such as cameras!). Client comes back and says "Use phone gap".

Its an awful platform, and end users can just tell they've been short changed with a wrapped web app, but the client is always right. So he gets his bloody phonegap app. Of course phone gap actually doesn't make things "write once run anywhere", because you need to recreate UIs to look native on both apps (And no, jquery mobile etc do NOT look "native"). Then apple bounces it saying basically "Its not native, gtfo" , so we have to rewrite the ios one natively , which fortuantely doesnt take too long since ObjC is a surprisingly productive language when you wrap your head around its eccentricities. And now we have a javascript mess running on android and a slick as hell IOS one. The whole thing ended up costing MORE than the original quote for native on both platform and whilst the droid one LOOKS ok, its pretty obviously not native simply by the lagginess when a processor intensive operation happens, since at the time (Not sure about now) phonegap on the droid didnt support webgl, so I couldnt use shaders for the faux instagram type effects.

He's dead right about this. HTML5 is a dead end technology on mobiles.

Re:More Full Response (1)

Anonymous Coward | 1 year,15 days | (#44282791)

Its an awful platform, and end users can just tell they've been short changed with a wrapped web app...HTML5 is a dead end technology on mobiles.

Your conclusion doesn't really follow at all. You use a crap platform to make an app produced to unrealistic and misguided customer technical interference, then spent an extra amount of time rewriting the iOS version of it, hence HTML5 sucks.

What?

Re:More Full Response (1)

CadentOrange (2429626) | 1 year,15 days | (#44282269)

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 other issue you're not addressing it runtime memory requirements. From the GC performance chart, the best performing GC that provides near native performance does so by requiring 5x more memory. This is going to impact the number of concurrently running apps on your phone/tablet before things start slowing down. Users prize snappy interfaces and if their mobile device slows down then the knowledgable users will bring up a task manager to figure out what's going on.

Do you want to stick around to see what they'd write on your app's page in the App Store?

Re:More Full Response (0)

Anonymous Coward | 1 year,15 days | (#44282785)

This is going to impact the number of concurrently running apps on your phone/tablet before things start slowing down.

This isn't even a use case on mobile devices. It's not like you're running a windowed operating system on them. Android for example aggressively kills off anything that isn't currently active.

TLDR version (4, Informative)

Rob_Bryerton (606093) | 1 year,16 days | (#44281345)

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.

Re:TLDR version (1, Informative)

drcheap (1897540) | 1 year,16 days | (#44281441)

Your super short summary was still 3 paragraphs long... TL;DR indeed!

Re:TLDR version (1)

Anonymous Coward | 1 year,16 days | (#44281501)

A better summary would be...

Friends don't let friends use garbage collected languages.

Re:TLDR version (0)

angel'o'sphere (80593) | 1 year,15 days | (#44282349)

If you are in a "low memory situation" in a managed language, you likely would be in one in a manual managed language as well.
Bottom line it boils down how huge the problems are you want to tackle and how naive your approach is.
I would assume a programmer with ten years of experience in C/C++ or similar is likely less naive than a 'similar' experienced Java or C# programmer.
I would expect an experienced developr to know his platform, but in our days it is no longer so painfull needed. If your team sucks because it can not tackle the platform, it is often possible to hire an expert. In the old days YOU where expected to be the expert and to know what you did.
E.g. in the blog article the author brings up an example where you (in his opinion) have the same data 5 times in various buffers. A picture taken by the camera, while the camara shows the scene, and the picture is in a buffer while it is written to disk, and scaled somewhere else and uploaded to a website at the same time (using up another buffer). Well, first off all the two buffers for disk and network don't buffer the whole image, but a "block" or a few "blocks". Second of all this problem is completely language independent. The buffers likely not even exist in the "application" space but in the "device drivers".
The argumentation of that author was as naive as many programers are when they apply "straigth forward" algorithms to huge data sets.

oblig: why is this on Slashdot? (0)

Anonymous Coward | 1 year,15 days | (#44281899)

..."that we should incentivize good, evidence-based, interesting discussion and discourage writing witty comments."

Next, he'll expect you to read the 10,000 word article!

Something wrong here (1)

vikingpower (768921) | 1 year,15 days | (#44282037)

The very same blog post was already the subject of an article on Slashdot last week. What is going on here ??

Both submissions Opera is ignored (1)

Trax3001BBS (2368736) | 1 year,15 days | (#44282047)

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.

Re:Both submissions Opera is ignored (0)

Anonymous Coward | 1 year,15 days | (#44282811)

The current Opera versions are wrappers around Chrome, so you can look at the V8 figures and imagine its Opera.

"bikesheding"??? (0)

Anonymous Coward | 1 year,15 days | (#44282347)

What in Sam Hill does that mean?

Re:"bikesheding"??? (1)

Anonymous Coward | 1 year,15 days | (#44282485)

See http://bikeshed.com/ [bikeshed.com]
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>