My MacBook Pro runs JavaScript 26.7x as fast as my iPad(globelogger.com)
globelogger.com
My MacBook Pro runs JavaScript 26.7x as fast as my iPad
http://www.globelogger.com/2010/04/my-macbook-pro-runs-javascript-267x-as-fast-as-my-ipad.html
42 comments
It would be interesting to see a comparison of Javascript performance per Watt.
Does it make a difference though? I think oit's plenty fast enough to run most non-game apps. It would help to see an app that's hindered by it before proclaiming a BFD.
> "Does it make a difference though?"
Yes, a million times yes.
> "I think oit's plenty fast enough to run most non-game apps."
Right, and that's the same argument used by a bajillion people before someone else came and ate their lunch (including Apple!). Nokia had a functional, but slow, sluggish, and substandard user experience on their phones. Apple came in and stomped all over that with their slick, super-fast, snappy UI.
IE was functional - sites worked and all - but was slow and bloated when Firefox came along and blew it out of the water in every way that mattered.
Performance always matters. When you're making the "meh, good enough" argument, you're in a prime position to be taken out spectacularly by a competitor who cares.
The complexity of JS-based webapps is going to get higher, not lower. A web-browsing device that performs JavaScript badly is a BFD.
Yes, a million times yes.
> "I think oit's plenty fast enough to run most non-game apps."
Right, and that's the same argument used by a bajillion people before someone else came and ate their lunch (including Apple!). Nokia had a functional, but slow, sluggish, and substandard user experience on their phones. Apple came in and stomped all over that with their slick, super-fast, snappy UI.
IE was functional - sites worked and all - but was slow and bloated when Firefox came along and blew it out of the water in every way that mattered.
Performance always matters. When you're making the "meh, good enough" argument, you're in a prime position to be taken out spectacularly by a competitor who cares.
The complexity of JS-based webapps is going to get higher, not lower. A web-browsing device that performs JavaScript badly is a BFD.
The complexity of JS-based webapps is going to get higher, not lower.
Only if that's the winning tradeoff. If, in fact, "ability to run well on a mobile device that is desperate to conserve battery power" turns out to be a more valuable trait in a particular segment of the market than "has lots and lots of complex JS logic that takes power to run" then software will evolve accordingly.
Only if that's the winning tradeoff. If, in fact, "ability to run well on a mobile device that is desperate to conserve battery power" turns out to be a more valuable trait in a particular segment of the market than "has lots and lots of complex JS logic that takes power to run" then software will evolve accordingly.
It certainly matters but it might just be the right trade-off in this situation. Or not.
I think nobody would argue that performance doesn’t matter, it’s just that you can’t always have everything and then you better pick the right stuff. Apple probably thinks that JS performance is good enough. For now. And that’s a attitude I would have no problems with.
I think nobody would argue that performance doesn’t matter, it’s just that you can’t always have everything and then you better pick the right stuff. Apple probably thinks that JS performance is good enough. For now. And that’s a attitude I would have no problems with.
> "It certainly matters but it might just be the right trade-off in this situation. Or not."
In principle, yes, but if you're marketing a device that is some kind of ultimate web-browsing machine, and you have to crank down JS performance to hit battery life... then the technology for your device isn't there yet.
Apple has made the claim forever that they don't execute until the right technologies are there (an argument they repeated for iPad) - and have frequently accused competitors of launching something before it's ready (IMHO, a valid point). This would seem to fit into that case - assuming JS performance is deliberately low as a trade for battery life.
In principle, yes, but if you're marketing a device that is some kind of ultimate web-browsing machine, and you have to crank down JS performance to hit battery life... then the technology for your device isn't there yet.
Apple has made the claim forever that they don't execute until the right technologies are there (an argument they repeated for iPad) - and have frequently accused competitors of launching something before it's ready (IMHO, a valid point). This would seem to fit into that case - assuming JS performance is deliberately low as a trade for battery life.
Depending on the application. The ipad is much more dependent on webapps so performance is important.
Here on a Macbook Pro (Chrome latest version), Google docs is not always a pleasant experience -- especially when opening nontrivial spreadsheets.
Here on a Macbook Pro (Chrome latest version), Google docs is not always a pleasant experience -- especially when opening nontrivial spreadsheets.
Yes, it does.
I wrote a small HTML5 offline-capable web app, processing a ~100KB JSON file with around 200 items. For ease of development, I initially used a JSON query library, which was perfectly fast on my laptop, a bit pokey on my 3GS, and - as I found out rather late - amazingly slow on an iPhone 3G.
I removed the library in question and rewrote my queries to use JS1.6's filter function; along with some template optimization, I managed to get the delay down to somewhat reasonable... but it's still a touch pokey on original 3G iPhones and older Android phones for my tastes.
There's likely more optimization I could have done, but I tested far too late on slower devices and just didn't have enough time. In the future we're looking at either writing a native app or using HTML5 database storage - but most importantly, testing far more regularly on slower devices. We've also reconsidered writing some truly large applications in HTML5, as we're rather worried devices will just be too slow, and we won't find out until late in development.
(The app in question is http://pax.expojunkie.com/, if anyone wants to take a look.)
tl;dr: Yes, JavaScript performance can be a problem. If you're writing a JavaScript-heavy site, get the slowest device you expect your users to have and test it regularly.
I wrote a small HTML5 offline-capable web app, processing a ~100KB JSON file with around 200 items. For ease of development, I initially used a JSON query library, which was perfectly fast on my laptop, a bit pokey on my 3GS, and - as I found out rather late - amazingly slow on an iPhone 3G.
I removed the library in question and rewrote my queries to use JS1.6's filter function; along with some template optimization, I managed to get the delay down to somewhat reasonable... but it's still a touch pokey on original 3G iPhones and older Android phones for my tastes.
There's likely more optimization I could have done, but I tested far too late on slower devices and just didn't have enough time. In the future we're looking at either writing a native app or using HTML5 database storage - but most importantly, testing far more regularly on slower devices. We've also reconsidered writing some truly large applications in HTML5, as we're rather worried devices will just be too slow, and we won't find out until late in development.
(The app in question is http://pax.expojunkie.com/, if anyone wants to take a look.)
tl;dr: Yes, JavaScript performance can be a problem. If you're writing a JavaScript-heavy site, get the slowest device you expect your users to have and test it regularly.
Ohhh, yes it does. My company is currently working on a quite complex Web-UI and it's a huge (!!) difference.
As according to everyone the web shall displace desktop apps in about every area, this means that really complex web application must be able to run.
A slow browser will only lead to the webapps we have today which are not very complex in comparison to full fledged desktop apps (see Google Docs vs. Office, Mailclient vs. gmail, etc.).
As according to everyone the web shall displace desktop apps in about every area, this means that really complex web application must be able to run.
A slow browser will only lead to the webapps we have today which are not very complex in comparison to full fledged desktop apps (see Google Docs vs. Office, Mailclient vs. gmail, etc.).
If everyone bought an iPad your company's product would die, not the iPad.
Right, that's why i said, that we still have no complex Web UIs. The ipad wouldn't die for sure, but it's slowing down progress to better web applications if webbrowsers are slow (and i don't mean ipad in particular every browser that is sub par in performance).
If browsers continue to perform that different and also continue to implement different features with different syntax, where will this lead? To web apps that are built for the slowest browser and the most minimal features available. The only way out of this dead end, that i see are web applications that are just browser specific (aka "The website was developed and tested with browser XXX. Please download XXX _here_ or continue on your own risk").
And both ways sound horrible to me. Look at some HTML5 "tech demos" and see what web apps could be capable of and then look at the web. We are still years behind and it will take several more years to have web sites that implement new features.
If browsers continue to perform that different and also continue to implement different features with different syntax, where will this lead? To web apps that are built for the slowest browser and the most minimal features available. The only way out of this dead end, that i see are web applications that are just browser specific (aka "The website was developed and tested with browser XXX. Please download XXX _here_ or continue on your own risk").
And both ways sound horrible to me. Look at some HTML5 "tech demos" and see what web apps could be capable of and then look at the web. We are still years behind and it will take several more years to have web sites that implement new features.
Just shows what a shitty platform HTML is: one step forward, three steps back
I'm surprised the gap isn't much larger.
Why? 2.66 GHz / 1 GHz is only 2.66x; that means there's a factor of ten difference due to software and processor architecture.
Those are the max. speeds. In power-saving mode, I highly doubt the iPad runs at 1Ghz for anything.
What's the point of having a 1 GHz processor if you never run it at that speed?
It's a very common process to reduce heat and power consumption. For instance all the previous iphone and ipod touch underclocked their processor and the new HTC incredible underclocks. Just about every embedded device underclocks as a higher speed processor often runs more efficiently at a lower speed than a processor designed to run at that speed.
If the iPad never runs at 1 GHz then we have a case of false advertising. If the iPad sometimes runs at 1 GHz, just not when executing JavaScript, that still sounds like a mistake given the complaints in this thread about sluggish performance.
(Disclaimer: I do power management for a living but I haven't used an iPad.)
(Disclaimer: I do power management for a living but I haven't used an iPad.)
It could be that for short bursts (which usually come immediately after user interaction), they use the full clock speed, but for long running computations, they throttle down.
Using the same test, my MBP is 206 times faster (@347ms) than my 3GS (@17559ms).
As long as we are picking on portables, my iMac is 340 times faster than my iPhone (original model).
I can say that frequently make a frowney face at my iPhone and wonder what the heck it is doing while I wait, but that I never have done that to my iPad. So while the iPad browser is not in the running for "fastest javascript platform on the planet", it is "fast" for everything I've done in real life with it.
I can say that frequently make a frowney face at my iPhone and wonder what the heck it is doing while I wait, but that I never have done that to my iPad. So while the iPad browser is not in the running for "fastest javascript platform on the planet", it is "fast" for everything I've done in real life with it.
17559/347 = 50 times faster.
Demo of "fast" HTML5 in iPad: http://www.youtube.com/watch?v=rfmbZkqORX4
Edit: put "fast" in quotes per the suggestion below
Edit: put "fast" in quotes per the suggestion below
you should have put 'fast' in quotes.
for those who haven't watched it, it's a video about how awful the HTML5 experience is on the iPad so far, not only because of speed but because developers haven't developed for the touch events.
for those who haven't watched it, it's a video about how awful the HTML5 experience is on the iPad so far, not only because of speed but because developers haven't developed for the touch events.
The reason that it IS a BFD is that Steve Jobs is now saying they have "high performance HTML5" on iPad. This is evidently not true. Here is an app for which it makes a big difference, something I prepared on my MacBook Pro (with the iPad in mind) only to be pwned by Apple's anti-competitive exclusion of the JS JIT compiler from iPad Safari: http://grokware.com/ff.php
How exactly is that exclusion anti-competitive? Presumably Apple wants JS to be fast on the iPad just as much as anyone else does, and would only exclude something like that for a good reason.
You presume too much. Think, man. Free high-performance HTML5 web apps are 1) not under their control and 2) not profit-making for Apple, as they bypass the App Store.
You honestly think that Apple would deliberately hamstring javascript performance on the iPad so that people have to use native apps? I think it's pretty ludicrous to think they'd do that: their sales of the iPad are directly, heavily affected by perceived performance of the device. If it's slow, people won't buy it.
How many extra apps do you think that move would make people buy: 2? 5? So you think they'd cripple performance and lose hundreds of thousands of sales so that they can get people to spend an extra $20 or so at the app store, of which they'll get all of $6? If they wanted your extra $6 that badly they'd just up the price on the device.
I just don't understand this constant assumption that every decision Apple makes is anti-competitive and designed to achieve lockin. Isn't it way more rational to assume that they want to make the device as good as possible because they make money by selling devices, and that their decisions are primarily driven by that motive?
How many extra apps do you think that move would make people buy: 2? 5? So you think they'd cripple performance and lose hundreds of thousands of sales so that they can get people to spend an extra $20 or so at the app store, of which they'll get all of $6? If they wanted your extra $6 that badly they'd just up the price on the device.
I just don't understand this constant assumption that every decision Apple makes is anti-competitive and designed to achieve lockin. Isn't it way more rational to assume that they want to make the device as good as possible because they make money by selling devices, and that their decisions are primarily driven by that motive?
Naive.
I got -4 karma points on this, for refusing to answer point by point the arguments of a naive Apple fanboy. I'll go back to just scanning HN, instead of participating. I've been a professional programmer for over 30 years, Written for Macs since 1984, I know what I'm talking about, and I find the current generation of developers to be, well, babies.
On the contrary, it was quite civil and thought provoking. It was simply terse, elegant, and to the point. "Naive" needn't have been interpreted as a personal attack, it was a sufficient and complete summary of the argument presented, implying it undeserving of response. Only lack of creative imagination would consider "Naive" not thought-provoking. It is not my responsibility to hand-hold and lead a conversation. If someone cannot immediately mentally extrapolate the implications of a statement, maybe they should ponder it and explore the possible meanings, giving me the benefit of the doubt as to poignancy. Instead, they vote it down, because it's not full of the superficial spoon-fed explicitness the down-voters expect.
That wasn't a civil and thought-provoking contribution to the discussion, which is what HN at its best is about.
I like the part where you addressed the glaring holes he pointed out in your argument and provided compelling counterpoints.
Apple makes (much) more money selling iPad hardware than they make selling apps. They are not going to make more money by intentionally crippling Javascript performance, especially after so publicly touting it as an alternative to Flash.
If you're going to make up some conspiracy theory, at least make sure it has some foundation in logic.
If you're going to make up some conspiracy theory, at least make sure it has some foundation in logic.
Incidentally, I just tried the latest "fastest ever" Google Chrome with this. The frame rate DROPPED on my machine from 48fps to 18fps. I'm getting the feeling that pushing the performance limits of compiled JavaScript is not an effective endeavor right now.
I got 12961ms on my HTC Desire (Android, 1Ghz cpu).
24088 on the Palm Pre. (Dual core 500mhz)