6 ms·

Safari Vs Chrome iOS JavaScript Benchmark

27 points by dkokelley 14y ago

conradev 14y ago
I think a Chrome engineer at I/O summed it up best, from the Campfire session for Chrome/OS: There's raw performance, and there's usability. Both determine how fast you get your content. Where Safari wins out in performance due to restrictions on iOS, Chrome wins out in usability. The Omnibox, for example, recognizes my favorite sites after I type just a few characters. Plus, syncing.
wedtm 14y ago
... Chrome on iOS is using the native iOS render, IIRC. So wouldn't this test be testing the same thing?
- jasonlotito 14y ago
  No, not exactly. Chrome is using the web view without JIT compiling for JavaScript that Safari can take advantage of. That being said, it's not something that's surprising. It's a known issue.
- geoffpado 14y ago
  No, apps using UIWebView don't get the "fast" JS engine, for security reasons. Only MobileSafari has that. EDIT: Gah, beaten by a few seconds by jasonlotito.
- deleted 14y ago
  [deleted]
- dkokelley 14y ago
  From what I understand, Chrome (and any non-native app) doesn't have access to the JavaScript engine that Safari does. That's why the JavaScript benchmark results are so disparate between Safari and Chrome for iOS.
mschalle 14y ago
It looks better and feels snappier, so these tests are surprising...
- dkokelley 14y ago
  It wouldn't surprise me to discover that Google's team did lots of their own performance tweaking and tuning to compensate for their disadvantage. I do love the responsiveness. Now their Gmail app on the other hand was painful for me to use.
  - mschalle 14y ago
    Yeah I could never really tell how that even made it to the App Store. Some stupid wrapper around the web page, but the Chrome app is definitely more along the lines of what I'd expect from Google.
  - urbanjunkie 14y ago
    The latest update to the GMail app for iOS is vastly improved.
    - bballdeo 14y ago
      How does it compare to Sparrow?
- urbanjunkie 14y ago
  The snappiness could be because iOS Chrome pre-fetches pages if you're on a wifi network. A lot of the lag of Safari on iOS seems to be in the actual fetching of pages.
- cliftonk 14y ago
  These tests are only JavaScript benchmarks and don't reflect real-world usage well. Chrome for iOS has a custom network stack and (like someone else said) page prefetching among other things.
- quonn 14y ago
jcampbell1 14y ago
Can someone explain how an application developer with access to webkit+Nitro could cause problems? Would the developer have to write a malicious app, or would a maliciously crafted webpage be able to exploit the OS?
- gnubardt 14y ago
  If the JIT engine in Nitro had a JIT Spray vulnerability and Nitro was a shared library could it allow an attacker to inject code into other applications that also use Nitro? Not that shared libraries are a problem, just that JIT'ing introduces a new attack vector that is hard to secure. http://en.wikipedia.org/wiki/JIT_spraying http://en.wikipedia.org/wiki/JIT_spraying
- Xuzz 14y ago
  iOS code signs all code that runs on the system. Compared to most other operating systems, this is a huge security win: without another exploit in that system, even a standard remote code execution vulnerability is useless. Nitro generates code at runtime, so it (by definition) needs to run unsigned code. With Safari, Apple can audit all the code necessary, but with third party apps, it would be easy for a developer to have their app exploited or even use the unsigned code ability to download new, possibly malicious code after the App Store review process.
  - lucian1900 14y ago
    Except there are always exploits in signed code on that platform, in the form of jailbreaks. It's a weak argument at best.
    - briandear 14y ago
      Yes, but users don't accidentally jailbreak their devices.
      - superasn 14y ago
        I'm not an expert at this so please correct me if I'm wrong, but if I remember correctly all I had to do to jailbreak my iphone was go to jailbreakme.com and click the button on it. That was it. So it seems that if I can trick someone to click that button then it is possible for me to not only jailbreak their phone but also run any sort of malicious code afterwards (because instead of Cydia it can install just about anything).
ltcoleman 14y ago
These benchmarks are not surprising. The UI however is the biggest turn-on. Chrome for iOS was very well done even though it is NOT Chrome.
structAnkit 14y ago
While third-party browsers won't be able to compete with Safari on iOS due to the technical limitations, I still prefer Chrome on my iPhone because it ties in with my Google account, syncing everything for me. The loss in per-page performance is somewhat mitigated by the fact that I have to load fewer pages than before thanks to features such as Chrome to Mobile and syncing of tabs, bookmarks, and passwords. Also, Chrome is so well designed for mobile as on my Galaxy Nexus that it is difficult to switch to any other browser. The way they handle tabs is the best I've seen. Incognito mode also offers an easy way to simulate a second browser session without switching to another browser app, something I as a web developer cannot live without.
- clutchrockwell 14y ago
  I am also happy to take the performance hit in stride in exchange for the sync features. The "request desktop version" feature is also nicely implemented.
mtgx 14y ago
What is the point of UIWebView, if it's meant to help developers write Javascript "native" apps, and yet it's 3x slower than a web app would be inside Mobile Safari? Doesn't that kind of defeat the purpose of UIWebView existing? I'm pretty sure Apple is leaving this as it is on purpose so Javascript apps don't start to compete on performance with ObjectiveC apps, and the security excuse they give is just the lazy one to get them off the hook, just like Microsoft is saying "WebGL poses security issues, so we won't even try to add it". Well guess what. A lot of stuff poses security issues. But you have to balance that out with the features and usability you want to give to the user, and if there are some good and "logical" features you could add like setting other browsers as default, or letting UIWebView apps be as fast as web apps in Safari, then you just have to add them and make sure the security is as tight as possible. Add a sandbox if necessary and so on. Don't take the easy way out.
- kombine 14y ago
  That is the reason of total control over their platform, and that's where industry is going - Microsoft is also imposing the same restrictions in Windows RT. That is quite sad, because it doesn't leave much freedom to the programmers, demoting them to just the "apps" coders, there is no place for hackers in its true meaning.
- superasn 14y ago
  > Well guess what. A lot of stuff poses security issues. But you have to balance that out with the features and usability you want to give to the user Just imagine if Microsoft had done the same starting with Windows 3.1. How much innovation would it have killed? I recently tried using Adobe AIR to make something, but unlike C# the AIR API is severely sandboxed and limited that even simple things like GetDC or CreateShortcut are just near impossible to implement. End result is I never really completed my app.. something which would have taken me an hour at most to do in C#. This new trend of technology where everything is being sandboxed and scrutinized for approval in the name of security is really very sad for hacker culture.
  - taligent 14y ago
    All we are talking about here is a loss of performance in Javascript benchmarks. In every day usage you simply don't notice a difference between Chrome and Safari. So I think you have the volume turned to 11 on the idea of it killing innovation.
dchest 14y ago
Does WebKit on iOS ships with LLInt? I think not, so there's a room for improvement for unJITted version. http://trac.webkit.org/changeset/108309 http://trac.webkit.org/changeset/108309 http://wingolog.org/archives/2012/06/27/inside-javascriptcores-low-level-interpreter http://wingolog.org/archives/2012/06/27/inside-javascriptcor...
amosel 14y ago
V8WebView?

27 points by dkokelley 14y ago

I think a Chrome engineer at I/O summed it up best, from the Campfire session for Chrome/OS: There's raw performance, and there's usability. Both determine how fast you get your content. Where Safari wins out in performance due to restrictions on iOS, Chrome wins out in usability. The Omnibox, for example, recognizes my favorite sites after I type just a few characters. Plus, syncing.

wedtm 14y ago

... Chrome on iOS is using the native iOS render, IIRC. So wouldn't this test be testing the same thing?

jasonlotito 14y ago
No, not exactly. Chrome is using the web view without JIT compiling for JavaScript that Safari can take advantage of. That being said, it's not something that's surprising. It's a known issue.
geoffpado 14y ago
No, apps using UIWebView don't get the "fast" JS engine, for security reasons. Only MobileSafari has that. EDIT: Gah, beaten by a few seconds by jasonlotito.
deleted 14y ago
[deleted]
dkokelley 14y ago
From what I understand, Chrome (and any non-native app) doesn't have access to the JavaScript engine that Safari does. That's why the JavaScript benchmark results are so disparate between Safari and Chrome for iOS.

mschalle 14y ago

It looks better and feels snappier, so these tests are surprising...

dkokelley 14y ago
It wouldn't surprise me to discover that Google's team did lots of their own performance tweaking and tuning to compensate for their disadvantage. I do love the responsiveness. Now their Gmail app on the other hand was painful for me to use.
- mschalle 14y ago
  Yeah I could never really tell how that even made it to the App Store. Some stupid wrapper around the web page, but the Chrome app is definitely more along the lines of what I'd expect from Google.
- urbanjunkie 14y ago
  The latest update to the GMail app for iOS is vastly improved.
  - bballdeo 14y ago
    How does it compare to Sparrow?
urbanjunkie 14y ago
The snappiness could be because iOS Chrome pre-fetches pages if you're on a wifi network. A lot of the lag of Safari on iOS seems to be in the actual fetching of pages.
cliftonk 14y ago
These tests are only JavaScript benchmarks and don't reflect real-world usage well. Chrome for iOS has a custom network stack and (like someone else said) page prefetching among other things.
quonn 14y ago

jcampbell1 14y ago

Can someone explain how an application developer with access to webkit+Nitro could cause problems? Would the developer have to write a malicious app, or would a maliciously crafted webpage be able to exploit the OS?

gnubardt 14y ago
If the JIT engine in Nitro had a JIT Spray vulnerability and Nitro was a shared library could it allow an attacker to inject code into other applications that also use Nitro? Not that shared libraries are a problem, just that JIT'ing introduces a new attack vector that is hard to secure. http://en.wikipedia.org/wiki/JIT_spraying http://en.wikipedia.org/wiki/JIT_spraying
Xuzz 14y ago
iOS code signs all code that runs on the system. Compared to most other operating systems, this is a huge security win: without another exploit in that system, even a standard remote code execution vulnerability is useless. Nitro generates code at runtime, so it (by definition) needs to run unsigned code. With Safari, Apple can audit all the code necessary, but with third party apps, it would be easy for a developer to have their app exploited or even use the unsigned code ability to download new, possibly malicious code after the App Store review process.
- lucian1900 14y ago
  Except there are always exploits in signed code on that platform, in the form of jailbreaks. It's a weak argument at best.
  - briandear 14y ago
    Yes, but users don't accidentally jailbreak their devices.
    - superasn 14y ago
      I'm not an expert at this so please correct me if I'm wrong, but if I remember correctly all I had to do to jailbreak my iphone was go to jailbreakme.com and click the button on it. That was it. So it seems that if I can trick someone to click that button then it is possible for me to not only jailbreak their phone but also run any sort of malicious code afterwards (because instead of Cydia it can install just about anything).

ltcoleman 14y ago

These benchmarks are not surprising. The UI however is the biggest turn-on. Chrome for iOS was very well done even though it is NOT Chrome.

structAnkit 14y ago

While third-party browsers won't be able to compete with Safari on iOS due to the technical limitations, I still prefer Chrome on my iPhone because it ties in with my Google account, syncing everything for me. The loss in per-page performance is somewhat mitigated by the fact that I have to load fewer pages than before thanks to features such as Chrome to Mobile and syncing of tabs, bookmarks, and passwords. Also, Chrome is so well designed for mobile as on my Galaxy Nexus that it is difficult to switch to any other browser. The way they handle tabs is the best I've seen. Incognito mode also offers an easy way to simulate a second browser session without switching to another browser app, something I as a web developer cannot live without.

clutchrockwell 14y ago
I am also happy to take the performance hit in stride in exchange for the sync features. The "request desktop version" feature is also nicely implemented.

mtgx 14y ago

What is the point of UIWebView, if it's meant to help developers write Javascript "native" apps, and yet it's 3x slower than a web app would be inside Mobile Safari? Doesn't that kind of defeat the purpose of UIWebView existing? I'm pretty sure Apple is leaving this as it is on purpose so Javascript apps don't start to compete on performance with ObjectiveC apps, and the security excuse they give is just the lazy one to get them off the hook, just like Microsoft is saying "WebGL poses security issues, so we won't even try to add it". Well guess what. A lot of stuff poses security issues. But you have to balance that out with the features and usability you want to give to the user, and if there are some good and "logical" features you could add like setting other browsers as default, or letting UIWebView apps be as fast as web apps in Safari, then you just have to add them and make sure the security is as tight as possible. Add a sandbox if necessary and so on. Don't take the easy way out.

kombine 14y ago
That is the reason of total control over their platform, and that's where industry is going - Microsoft is also imposing the same restrictions in Windows RT. That is quite sad, because it doesn't leave much freedom to the programmers, demoting them to just the "apps" coders, there is no place for hackers in its true meaning.
superasn 14y ago
> Well guess what. A lot of stuff poses security issues. But you have to balance that out with the features and usability you want to give to the user Just imagine if Microsoft had done the same starting with Windows 3.1. How much innovation would it have killed? I recently tried using Adobe AIR to make something, but unlike C# the AIR API is severely sandboxed and limited that even simple things like GetDC or CreateShortcut are just near impossible to implement. End result is I never really completed my app.. something which would have taken me an hour at most to do in C#. This new trend of technology where everything is being sandboxed and scrutinized for approval in the name of security is really very sad for hacker culture.
- taligent 14y ago
  All we are talking about here is a loss of performance in Javascript benchmarks. In every day usage you simply don't notice a difference between Chrome and Safari. So I think you have the volume turned to 11 on the idea of it killing innovation.

dchest 14y ago

Does WebKit on iOS ships with LLInt? I think not, so there's a room for improvement for unJITted version. http://trac.webkit.org/changeset/108309 http://trac.webkit.org/changeset/108309 http://wingolog.org/archives/2012/06/27/inside-javascriptcores-low-level-interpreter http://wingolog.org/archives/2012/06/27/inside-javascriptcor...

amosel 14y ago

V8WebView?