Sorry, Steve: iPhone 50 Percent Slower Than Android on Web(wired.com)
wired.com
Sorry, Steve: iPhone 50 Percent Slower Than Android on Web
http://www.wired.com/epicenter/2011/03/android-iphone-web/
11 comments
Isn't Nitro a Javascript engine? Why will it affect page load times?
That depends upon how they measured. From reading their methodology, it sounds like they may have ended their measurement when they got a "document complete" callback (in their nomenclature). That sounds as if they were listening for the UIWebViewDelegate's webViewDidFinishLoad: method. If the initial page load triggers some javascript at page load time to dynamically create elements in the DOM or do any other setup work, that could easily been within the scope of their measurement. Depending on what the Fortune 1000 websites look like, of course.
I wouldn't expect the absence of Nitro to dominate the measurement, however. (Edit: Blaze says that 15% of the time taken, on average, was inside of JavaScript execution, so apparently it's both true that it does not dominate and that faster execution would have made a meaningful change.) I still think their methodology is flawed, though, because the webViewDidFinishLoad: callback can be called multiple times in the loading of a single document. It's not clear which one they listened for: the first one? the last one?
http://stackoverflow.com/questions/908367/uiwebview-how-to-i...
Contrast this with the WebView in Android. It's not obvious what callback they would have used in that case, but looking at the documentation they probably would have listened for onPageFinished(), which appears to get called much earlier, because it is only called when the loading of the main frame is completed. (Again, according to the docs I found).
http://developer.android.com/reference/android/webkit/WebVie..., java.lang.String)
In order for their methodology to make any sense, one would have to conduct the measurements based on callbacks that have the same semantics. Do they? It doesn't look like it to me.
I wouldn't expect the absence of Nitro to dominate the measurement, however. (Edit: Blaze says that 15% of the time taken, on average, was inside of JavaScript execution, so apparently it's both true that it does not dominate and that faster execution would have made a meaningful change.) I still think their methodology is flawed, though, because the webViewDidFinishLoad: callback can be called multiple times in the loading of a single document. It's not clear which one they listened for: the first one? the last one?
http://stackoverflow.com/questions/908367/uiwebview-how-to-i...
Contrast this with the WebView in Android. It's not obvious what callback they would have used in that case, but looking at the documentation they probably would have listened for onPageFinished(), which appears to get called much earlier, because it is only called when the loading of the main frame is completed. (Again, according to the docs I found).
http://developer.android.com/reference/android/webkit/WebVie..., java.lang.String)
In order for their methodology to make any sense, one would have to conduct the measurements based on callbacks that have the same semantics. Do they? It doesn't look like it to me.
I know it is the Internet and I should be used to it now but when the first two words of the title are there purely as snark to rile up fan boys, I really lose interest in the article.
I keep imagining it like the writer prints out the article and then holds it up right in Steve Jobs' face, and then taunts him like he just won the Super Bowl.
"YEAH STEVE! HOW DO YOU LIKE THAT? 1.1 SECONDS FASTER BITCH! UNH!" Complete with pelvic thrusts. It makes me laugh while I close the tab and completely ignore anything that might have been redeemable about the actual article.
"YEAH STEVE! HOW DO YOU LIKE THAT? 1.1 SECONDS FASTER BITCH! UNH!" Complete with pelvic thrusts. It makes me laugh while I close the tab and completely ignore anything that might have been redeemable about the actual article.
I believe the word you're looking for is "crotchchop" http://www.fortunecity.com/olympia/mcmahon/48/multimedia/dxc...
And if you're not down with that...
From CNET:
Blaze backed away from its conclusion in light of the new data. Chief Technology Officer Guy Podjarny told CNET in a statement: This test leveraged the embedded browser which is the only available option for iPhone applications. Blaze was under the assumption that Apple would apply the same updates to their embedded browser as they would their regular browser. If this is not the case and according to Apple's response, it's certainly possible the embedded browser might produce different results. If Apple decides to apply their optimizations across their embedded browser as well, then we would be more than willing to create a new report with the new performance results.
http://news.cnet.com/8301-30685_3-20044325-264.html
Blaze backed away from its conclusion in light of the new data. Chief Technology Officer Guy Podjarny told CNET in a statement: This test leveraged the embedded browser which is the only available option for iPhone applications. Blaze was under the assumption that Apple would apply the same updates to their embedded browser as they would their regular browser. If this is not the case and according to Apple's response, it's certainly possible the embedded browser might produce different results. If Apple decides to apply their optimizations across their embedded browser as well, then we would be more than willing to create a new report with the new performance results.
http://news.cnet.com/8301-30685_3-20044325-264.html
There seems to be some surprise across the web at this result. Putting aside whether it is a valid result due to UIWebView bugs or the fact that the iPhone processor is clocked lower etc., I would have thought most people would have assumed a browser made by Google would be faster than a browser made by Apple. Google seemed to ignite, and often lead this browser speed competition that makes headlines so often these days.
I regularly see Chrome, Opera, Firefox and recently IE9 boasting the best times in a bunch of dubious benchmarks. Indeed the one that seems to get the most play these days is Sunspider, Apple's own javascript test which you would assume favors them to some degree. Apple's Safari, I don't see so much of. Why would these expectations be reversed in mobile?
I regularly see Chrome, Opera, Firefox and recently IE9 boasting the best times in a bunch of dubious benchmarks. Indeed the one that seems to get the most play these days is Sunspider, Apple's own javascript test which you would assume favors them to some degree. Apple's Safari, I don't see so much of. Why would these expectations be reversed in mobile?
[deleted]
This was an extremely clever study/press-release from Blaze.
The number of "news" outlets picking it up is staggering:
http://news.google.com/news/more?ncl=du8BOOH4hczn4YMB-i7ZmzI...
Congrats to them and thanks for the testing service.
The number of "news" outlets picking it up is staggering:
http://news.google.com/news/more?ncl=du8BOOH4hczn4YMB-i7ZmzI...
Congrats to them and thanks for the testing service.
I also noticed that the test sites were the sites of all the Fortune 1000 companies.
I'm thinking these might not be ideally representative of the kinds of sites I actually browse. Why not test some more content-rich sites, or the most popular sites, instead?
I'm thinking these might not be ideally representative of the kinds of sites I actually browse. Why not test some more content-rich sites, or the most popular sites, instead?
Follow up post on why the study was flawed: http://www.loopinsight.com/2011/03/17/study-comparing-androi...
[deleted]
I love open source approach of Android. Also I love IPhone design.
This is key, and arguably makes these kinds of discussions to be comparing apples and oranges. iPhone champions design aesthetic and top-down control, whereas Android champions OEM flexibility and a more open and multi-vendor compatibility. So Apple is not scrutinized enough, in my opinion, for the control being the only reason they can pull off their aesthetic. When you are trying to get multiple companies and technologies all working together, a lot more compromise has to be made for sure.
Article cleary states which Android phone was used in the test but doesnt state which iPhone was used. It just says iphone 4.2 and iphone 4.3. Does that mean a iphone 3g on 4.2 and a 3gs on ios 4.3?
The paper itself[1] says:
The study was done primarily on iPhone 4 and Google Nexus S.
[1]: http://www.wired.com/images_blogs/epicenter/2011/03/Android-...
The study was done primarily on iPhone 4 and Google Nexus S.
[1]: http://www.wired.com/images_blogs/epicenter/2011/03/Android-...
The "primarily" refers to the fact that they used a different Samsung phone for their Android 2.2 measurements. Android 2.2 is not available for the Nexus S, so they used the Galaxy S which is based on the same processor/chipset.
I missed the "detailed methodology" near the end. Thanks for pointing that out.
From the paper itself:
"We used iPhone 4 for the iPhone measurements, and Google Nexus S for Android 2.3 measurements. For our Android 2.2 measurements we chose the Samsung Galaxy S, since it has almost identical hardware to the Nexus S, making the OS the primary difference."
"We used iPhone 4 for the iPhone measurements, and Google Nexus S for Android 2.3 measurements. For our Android 2.2 measurements we chose the Samsung Galaxy S, since it has almost identical hardware to the Nexus S, making the OS the primary difference."
Ars says it was iPhone 4 running iOS 4.3 - http://arstechnica.com/gadgets/news/2011/03/nexus-s-beats-ip...
An argument can certainly be made that UIWebView being crippled is very much a platform negative (I would agree), but the "study" is purporting to represent the speed of browsing in Safari, which is plainly false.