Slashdot Mirror

Why is that every time you show some Android product has better feature or performance, call it X, than an competing Apple product the reply from Apple fans follows this logic..

People don't care about X

Eventually Apples popularity will start to fade and people WILL care.

You are assuming that Apple will not continue to define and re-define whole markets and classes of devices, as it has done repeatedly in its history. Honestly, to take but one example, do you really think we would even HAVE Honeycomb to compare iOS to if Apple hadn't released the iPad?

1 second difference can add up to a lot of time if you read many web pages, or you are searching for something. Just do the math. Say 100 modest amount web pages a day , 365 days a year. So you have (100*365)/3600 = 10.13 extra hours spent a year staring at screen that is doing nothing.

The flaw in your logic is that you spend zero time after the page loads doing things like figuring out what part of the page is relevant, scrolling to read desired content, picking your nose, etc. Ya know, the things that humans do, that an automated test does not. Now, if the difference was like 200 or 300%, then I would agree that it MIGHT matter to a HUMAN.

In both tests they used the embedded browser for both handsets respectively. From their testing suite I don't see how they could throw off the benchmark that much, 45,000 samples is a pretty significant sample size.

And the differences are not spectacular, and in the next couple of months, the iPhone 5 will whip on the Nexus. So what? Until Apple and Google decide to synchronize their hardware and software releases (not bloody likely), there will continue to be a back-and-forth "winner", as each respective platform updates themselves asynchronously with the other.

More on there testing methodology is here http://www.blaze.io/mobile/methodology/ . Finally the second link is complaints from Apple iOS developers. iOS 4.3 browser cannot use the new Nitro javascript engine in full screen mode, html 5 caching is missing, and mode in which the page is drawn on the screen has changed such that it is slower than native apps. Bug or not, it currently slower and no one knows why except Apple.

And no one knows why Android's scrolling/swiping is jumpy except Google, apparently; because I sure haven't seen anyone posting links to FIXES for that issue, and many, many Android owners complain about just that on Slashdot every single day (some even in this thread).

Could be that a piece or twelve of iOS javascript engine-code could use a little tightening. Cool thing is, when Apple does that, EVERY iOS device that can run the updated code will be updated to do so. How long do you think such a change would take to propagate through the Android multiverse?

In other words, "Nunh-UNH!"

Are you referring to my post?. If so, more along the lines of: Why don't you actually look into the methodology and other information as opposed to AC's "Oh yeah! Well your test was stupid!"

Kinda like this.
“regards the tests as flawed because Blaze used its own proprietary application that doesn’t take advantage of Apple Safari browser’s Web-performance optimization” - Stated by Natalie Kerris, a spokeswoman Apple.
source: http://www.blaze.io/business/embeded-browser-vs-native-browser/

If AC had included this to support their statement they would have has some sort of basis for their claim. They'd still be wrong though. Apple admits that the Safari browser runs faster than the engine used as opposed to AC's claim that Blaze's application ran slower. What difference does that distinction make? Consider being a iOS developer wanting to using that engine for your application while competing against a similar application on Android.

They were using a custom app. Not the default browser. So what they are saying is that their app runs faster on the Nexus S. Not that the Nexus S is faster then the iPhone.

That's a bold assumption AC. How do you know it didn't run slower on the android phones? Have you bench marked each application?

Still, what do you expect them to do to get accurate results? Use the actual browsers and sit there with a stopwatch?

How would you approach the problem of getting accurate times?

Primary Source:
http://www.blaze.io/uncategorized/mobile/iphone-vs-android-45000-tests-prove-whose-browser-is-faster/

The measurement itself was done using the custom apps, which use the platform’s embedded browser. This means WebView (based on Chrome) for Android, and UIWebView (based on Safari) for iPhone. Manual verification showed that page load performance of the embedded browsers, when properly configured, is effectively identical to the stand-alone browsers. The load times are calculated using the “Document Complete” callback from the browser, which is a standard way of measuring a web page’s load time. As mentioned above, the agents are now a part of a free service available at http://blaze.io/mobile/, and we encourage you to try it out.

Methodology
http://www.blaze.io/mobile/methodology/

They were using a custom app. Not the default browser. So what they are saying is that their app runs faster on the Nexus S. Not that the Nexus S is faster then the iPhone.

That's a bold assumption AC. How do you know it didn't run slower on the android phones? Have you bench marked each application?

Still, what do you expect them to do to get accurate results? Use the actual browsers and sit there with a stopwatch?

How would you approach the problem of getting accurate times?

Primary Source:
http://www.blaze.io/uncategorized/mobile/iphone-vs-android-45000-tests-prove-whose-browser-is-faster/

The measurement itself was done using the custom apps, which use the platform’s embedded browser. This means WebView (based on Chrome) for Android, and UIWebView (based on Safari) for iPhone. Manual verification showed that page load performance of the embedded browsers, when properly configured, is effectively identical to the stand-alone browsers. The load times are calculated using the “Document Complete” callback from the browser, which is a standard way of measuring a web page’s load time. As mentioned above, the agents are now a part of a free service available at http://blaze.io/mobile/, and we encourage you to try it out.

Methodology
http://www.blaze.io/mobile/methodology/

They were using a custom app. Not the default browser. So what they are saying is that their app runs faster on the Nexus S. Not that the Nexus S is faster then the iPhone.

That's a bold assumption AC. How do you know it didn't run slower on the android phones? Have you bench marked each application?

Still, what do you expect them to do to get accurate results? Use the actual browsers and sit there with a stopwatch?

How would you approach the problem of getting accurate times?

Primary Source:
http://www.blaze.io/uncategorized/mobile/iphone-vs-android-45000-tests-prove-whose-browser-is-faster/

The measurement itself was done using the custom apps, which use the platform’s embedded browser. This means WebView (based on Chrome) for Android, and UIWebView (based on Safari) for iPhone. Manual verification showed that page load performance of the embedded browsers, when properly configured, is effectively identical to the stand-alone browsers. The load times are calculated using the “Document Complete” callback from the browser, which is a standard way of measuring a web page’s load time. As mentioned above, the agents are now a part of a free service available at http://blaze.io/mobile/, and we encourage you to try it out.

Methodology
http://www.blaze.io/mobile/methodology/

First, read the article written by the folks who did the test: http://www.blaze.io/uncategorized/mobile/iphone-vs-android-45000-tests-prove-whose-browser-is-faster/

Here, they address this point. First, they compared their app's times with Safari's times, and found no noticeable difference.

Nothing in your link supports this. Their update (http://www.blaze.io/business/embeded-browser-vs-native-browser/) basically admits that they ran a flawed test, and blames Apple for optimizing its browser.

Second, they point out that javascript performance accounts for a small fraction of the load times (see large yellow box at the top of the page), and if Nitro was not in use, they estimate that using it would improve Safari's load times, but would not dramatically change the results.

JavaScript is not the only difference between safari and an embedded web renderer. Safari has different caching and multithreading as well.

First, read the article written by the folks who did the test: http://www.blaze.io/uncategorized/mobile/iphone-vs-android-45000-tests-prove-whose-browser-is-faster/

Here, they address this point. First, they compared their app's times with Safari's times, and found no noticeable difference.

Nothing in your link supports this. Their update (http://www.blaze.io/business/embeded-browser-vs-native-browser/) basically admits that they ran a flawed test, and blames Apple for optimizing its browser.

Second, they point out that javascript performance accounts for a small fraction of the load times (see large yellow box at the top of the page), and if Nitro was not in use, they estimate that using it would improve Safari's load times, but would not dramatically change the results.

JavaScript is not the only difference between safari and an embedded web renderer. Safari has different caching and multithreading as well.

People don't care about X

Eventually Apples popularity will start to fade and people WILL care.
1 second difference can add up to a lot of time if you read many web pages, or you are searching for something. Just do the math. Say 100 modest amount web pages a day , 365 days a year. So you have (100*365)/3600 = 10.13 extra hours spent a year staring at screen that is doing nothing. In both tests they used the embedded browser for both handsets respectively. From their testing suite I don't see how they could throw off the benchmark that much, 45,000 samples is a pretty significant sample size.
More on there testing methodology is here http://www.blaze.io/mobile/methodology/ .
Finally the second link is complaints from Apple iOS developers. iOS 4.3 browser cannot use the new Nitro javascript engine in full screen mode, html 5 caching is missing, and mode in which the page is drawn on the screen has changed such that it is slower than native apps. Bug or not, it currently slower and no one knows why except Apple.

First, read the article written by the folks who did the test: http://www.blaze.io/uncategorized/mobile/iphone-vs-android-45000-tests-prove-whose-browser-is-faster/

Here, they address this point. First, they compared their app's times with Safari's times, and found no noticeable difference. Second, they point out that javascript performance accounts for a small fraction of the load times (see large yellow box at the top of the page), and if Nitro was not in use, they estimate that using it would improve Safari's load times, but would not dramatically change the results.