MobileSafari 対 Chrome for iOSのJavaScriptベンチマーク
2016/03/16
価値ある情報をユーザー視点で発信するブログ
2016/03/16
ひとりぶろぐのmoyashi (@hitoriblog) です。
ついに、iOS版のGoogle Chrome、Chrome for iOSがリリースされましたね。
Chrome – Google のウェブブラウザ
カテゴリ: Utilities
販売元: Google, Inc.(サイズ: 62.6 MB)
全てのバージョンの評価: (6,706 件の評価)
仔細は他ブログに譲るとして、JavaScriptベンチマークをやってみました。
体感では、Chrome for iOSはMobileSafariより速いように感じます。
試したベンチマークは、MobileSafariと、Chrome for iOSの両方が採用しているWebKitのオフィシャルベンチマークSunSpider。
JavaScriptの実行速度を計測するベンチマークです。純粋なJavaScriptのベンチマークで、DOM関係のスピードや、その他のブラウザAPIの速度は計測されません。
http://www.webkit.org/perf/sunspider/sunspider.html
各ブラウザ以外は、MobilePhone、Musicのみプロセスを残す状態で実行。
タブも、SunSpiderを実行するタブ以外は閉じた状態としました。
もくじ
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total: 2231.2ms +/- 0.9%
--------------------------------------------
3d: 277.2ms +/- 0.4%
cube: 96.9ms +/- 0.9%
morph: 72.0ms +/- 0.0%
raytrace: 108.3ms +/- 1.5%
access: 273.1ms +/- 0.6%
binary-trees: 48.0ms +/- 2.6%
fannkuch: 120.1ms +/- 0.2%
nbody: 69.7ms +/- 0.5%
nsieve: 35.3ms +/- 2.9%
bitops: 175.8ms +/- 0.7%
3bit-bits-in-byte: 28.9ms +/- 1.4%
bits-in-byte: 36.8ms +/- 0.8%
bitwise-and: 47.8ms +/- 3.3%
nsieve-bits: 62.3ms +/- 0.6%
controlflow: 19.1ms +/- 2.8%
recursive: 19.1ms +/- 2.8%
crypto: 160.7ms +/- 0.7%
aes: 95.1ms +/- 1.1%
md5: 36.6ms +/- 1.0%
sha1: 29.0ms +/- 0.0%
date: 317.4ms +/- 1.0%
format-tofte: 163.3ms +/- 1.3%
format-xparb: 154.1ms +/- 1.3%
math: 219.7ms +/- 0.5%
cordic: 77.9ms +/- 1.1%
partial-sums: 93.2ms +/- 0.5%
spectral-norm: 48.6ms +/- 0.8%
regexp: 88.5ms +/- 3.3%
dna: 88.5ms +/- 3.3%
string: 699.7ms +/- 2.7%
base64: 86.1ms +/- 2.7%
fasta: 91.3ms +/- 1.4%
tagcloud: 142.8ms +/- 5.2%
unpack-code: 242.2ms +/- 2.4%
validate-input: 137.3ms +/- 3.5%
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total: 9029.4ms +/- 0.2%
--------------------------------------------
3d: 1005.8ms +/- 0.3%
cube: 289.1ms +/- 0.7%
morph: 371.5ms +/- 0.2%
raytrace: 345.2ms +/- 0.4%
access: 1390.6ms +/- 0.1%
binary-trees: 124.0ms +/- 0.7%
fannkuch: 761.1ms +/- 0.3%
nbody: 310.1ms +/- 0.1%
nsieve: 195.4ms +/- 0.5%
bitops: 1196.8ms +/- 0.4%
3bit-bits-in-byte: 263.7ms +/- 1.5%
bits-in-byte: 290.4ms +/- 0.2%
bitwise-and: 235.6ms +/- 0.2%
nsieve-bits: 407.1ms +/- 0.2%
controlflow: 165.4ms +/- 3.2%
recursive: 165.4ms +/- 3.2%
crypto: 625.4ms +/- 0.7%
aes: 274.9ms +/- 1.7%
md5: 175.6ms +/- 0.5%
sha1: 174.9ms +/- 1.4%
date: 470.7ms +/- 0.2%
format-tofte: 264.8ms +/- 0.3%
format-xparb: 205.9ms +/- 0.5%
math: 966.5ms +/- 0.9%
cordic: 399.3ms +/- 2.3%
partial-sums: 302.6ms +/- 0.3%
spectral-norm: 264.6ms +/- 1.5%
regexp: 1676.6ms +/- 0.5%
dna: 1676.6ms +/- 0.5%
string: 1531.6ms +/- 0.2%
base64: 218.3ms +/- 0.2%
fasta: 257.4ms +/- 0.3%
tagcloud: 350.0ms +/- 0.3%
unpack-code: 458.2ms +/- 0.2%
validate-input: 247.7ms +/- 1.4%
結果はMobileSafariの方がChrome for iOSの4倍速い結果となりました。
これホント?
たぶんNitroエンジンがつかえないからだとおもいます【ブックマークレット使用不可】MobileSafari 対 Chrome for iOSのJavaScriptベンチマーク【辛い】 http://t.co/KOR16X9n @hitoriblogさんから
— するぷ (@isloop) June 28, 2012
@xxSANTAxx アプリから使えるWebViewはJITが効かない差別をされています。
— もっさりさん (@TeamMOSA2) June 29, 2012
ちなみに、TweetbotのWebViewでも同じベンチマークしてみました。
ほぼChrome for iOSと同じですね。
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total: 9115.8ms +/- 0.2%
--------------------------------------------
3d: 1015.9ms +/- 0.3%
cube: 294.4ms +/- 0.6%
morph: 373.4ms +/- 0.4%
raytrace: 348.1ms +/- 0.2%
access: 1405.5ms +/- 0.3%
binary-trees: 129.8ms +/- 1.7%
fannkuch: 764.1ms +/- 0.3%
nbody: 311.8ms +/- 0.2%
nsieve: 199.8ms +/- 0.2%
bitops: 1200.3ms +/- 0.1%
3bit-bits-in-byte: 263.0ms +/- 0.5%
bits-in-byte: 292.2ms +/- 0.4%
bitwise-and: 236.6ms +/- 0.2%
nsieve-bits: 408.5ms +/- 0.2%
controlflow: 163.2ms +/- 0.3%
recursive: 163.2ms +/- 0.3%
crypto: 623.2ms +/- 0.3%
aes: 271.9ms +/- 0.6%
md5: 177.5ms +/- 1.2%
sha1: 173.8ms +/- 0.2%
date: 490.4ms +/- 1.0%
format-tofte: 277.2ms +/- 1.0%
format-xparb: 213.2ms +/- 1.3%
math: 969.9ms +/- 0.8%
cordic: 400.8ms +/- 1.8%
partial-sums: 304.5ms +/- 0.4%
spectral-norm: 264.6ms +/- 0.5%
regexp: 1677.1ms +/- 0.1%
dna: 1677.1ms +/- 0.1%
string: 1570.3ms +/- 0.5%
base64: 225.1ms +/- 0.9%
fasta: 260.0ms +/- 0.3%
tagcloud: 355.4ms +/- 0.9%
unpack-code: 468.6ms +/- 0.8%
validate-input: 261.2ms +/- 1.8%
moyashi手製の調査ツールによれば、Chrome for iOSは普通にUIWebViewを使っているようです。WebKitとはいいながら、独自のブラウザエンジンを搭載しているのかと思いきや、そんなことはありませんでした。
それでも何となく速い気がするんですが、何なんでしょう?

Chromeのビュー構造をダンプしたものです。やはりUIWebView。
chrome_view_recursive_description.txt
難しいことは分かりませんが、キャッシュで検索するとcachedResponseなんていうのがあったりしますから、WebViewは標準のを使っていても、キャッシュをうまく効かせているのかもしれません。
grep -nH -i cache *
BookmarkEditViewController.h:65:- (void)discardCachedCells;
BookmarkPanelController.h:28: NSMutableDictionary *dominantColorCache_;
BookmarkPanelController.h:67:- (id)initWithLoader:(id)arg1 profile:(struct Profile *)arg2 colorCache:(id)arg3;
BrowserViewController.h:55: struct scoped_nsobject<NSMutableDictionary> dominantColorCache_;
BrowserViewController.h:56: struct scoped_nsobject<NSMutableDictionary> mostVisitedCompositeCache_;
BrowserViewController.h:79:- (void)deleteGreyCache;
BrowserViewController.h:80:- (void)createGreyCache:(int)arg1;
BundleImageCache.h:9:@interface BundleImageCache : NSObject
CDStructures.h:437:struct JKEncodeCache {
CDStructures.h:448: struct JKEncodeCache _field5[1024];
CDStructures.h:475:struct JKObjCImpCache {
CDStructures.h:502: struct JKTokenCache _field11;
CDStructures.h:503: struct JKObjCImpCache _field12;
CDStructures.h:521:struct JKTokenCache {
CDStructures.h:522: struct JKTokenCacheItem *_field1;
CDStructures.h:528:struct JKTokenCacheItem;
CDStructures.h:539: struct JKTokenCacheItem *_field5;
CDStructures.h:1077:struct TargetFrameCache {
GIPResourceLoader.h:13: unsigned int cacheSize_;
GIPResourceLoader.h:14: NSMutableDictionary *cache_;
GIPResourceLoader.h:20:+ (id)imageNamed:(id)arg1 fromLoader:(id)arg2 shouldCache:(BOOL)arg3;
GIPResourceLoader.h:27:- (id)imageNamed:(id)arg1 cache:(BOOL)arg2;
GIPResourceLoader.h:30:- (id)initWithCacheSize:(int)arg1 bundleName:(id)arg2;
GIPResourceLoader.h:31:- (id)initWithCacheSize:(int)arg1;
HttpProtocolHandler.h:25:- (id)cachedResponse;
HttpProtocolHandler.h:26:- (id)initWithRequest:(id)arg1 cachedResponse:(id)arg2 client:(id)arg3;
JSONDecoder.h:29:- (void)clearCache;
MostVisitedPanelController.h:24: NSMutableDictionary *compositeCache_;
MostVisitedPanelController.h:87:- (id)initWithLoader:(id)arg1 profile:(struct Profile *)arg2 compositeCache:(id)arg3;
NIImageMemoryCache.h:7:#import "NIMemoryCache.h"
NIImageMemoryCache.h:9:@interface NIImageMemoryCache : NIMemoryCache
NIMemoryCache.h:11:@interface NIMemoryCache : NSObject
NIMemoryCache.h:13: NSMutableDictionary *_cacheMap;
NIMemoryCache.h:14: NILinkedList *_lruCacheObjects;
NIMemoryCache.h:17:@property(retain, nonatomic) NILinkedList *lruCacheObjects; // @synthesize lruCacheObjects=_lruCacheObjects;
NIMemoryCache.h:18:@property(retain, nonatomic) NSMutableDictionary *cacheMap; // @synthesize cacheMap=_cacheMap;
NIMemoryCache.h:33:- (void)removeCacheInfoForName:(id)arg1;
NIMemoryCache.h:34:- (void)setCacheInfo:(id)arg1 forName:(id)arg2;
NIMemoryCache.h:35:- (id)cacheInfoForName:(id)arg1;
NIMemoryCacheInfo.h:11:@interface NIMemoryCacheInfo : NSObject
NINetworkRequestOperation.h:17: unsigned int _cachePolicy;
NINetworkRequestOperation.h:22:@property unsigned int cachePolicy; // @synthesize cachePolicy=_cachePolicy;
NewTabPageController.h:27: NSMutableDictionary *dominantColorCache_;
NewTabPageController.h:28: NSMutableDictionary *compositeCache_;
NewTabPageController.h:50:- (id)initWithUrl:(id)arg1 loader:(id)arg2 profile:(struct Profile *)arg3 colorCache:(id)arg4 compositeCache:(id)arg5;
Nimbus.h:15:+ (id)imageMemoryCache;
Nimbus.h:16:+ (void)setImageMemoryCache:(id)arg1;
SnapshotCache.h:11:@interface SnapshotCache : NSObject
SnapshotCache.h:18: struct ObjCPropertyReleaser propertyReleaser_SnapshotCache_;
SnapshotCache.h:28:- (void)removeGreyCache;
SnapshotCache.h:29:- (void)createGreyCache:(id)arg1;
SnapshotCache.h:35:- (void)purgeCacheOlderThan:(const struct Time *)arg1 keeping:(id)arg2;
SnapshotCache.h:37:- (struct FilePath)cacheDirectory;
Tab.h:120:- (void)commitCachedEntriesToHistoryDB;
TabModel.h:59:- (void)updateSnapshotCache:(id)arg1;
TabStripController.h:27: struct TargetFrameCache targetFrames_;
URLVerifyingProtocolHandler.h:21:- (id)initWithRequest:(id)arg1 cachedResponse:(id)arg2 client:(id)arg3;
WebController.h:52: BOOL useGreyImageCache_;
WebController.h:63:@property(nonatomic) BOOL useGreyImageCache; // @synthesize useGreyImageCache=useGreyImageCache_;
WebController.h:155:- (BOOL)shouldCacheSnapshot;
NSOperationのサブクラス、NIOperationなんていうのがあるので、うまいことHTTPリクエストを同時に出して高速化しているのかも?
@hitoriblog Chromeが早いのはリンク先先読みとか使ってるからじゃないでしょうか。
— そり (@sori_ja) June 29, 2012
@hitoriblog ちなみに、設定に「ウェブページのプリロード」項目があり、通常はWifiのみ有効になっています。
— そり (@sori_ja) June 29, 2012
設定の「プライバシー」の中に「ウェブページのプリロード」がありました。
デフォルトでは、「Wi-Fi接続時のみ」となっています。
これでリンク先の先読みをしているがゆえに速いのかも?

Chrome for iOSで「javascript:alert(1);」をブックマークから実行してみた結果が以下です。

ブックマークレット使えない……。ちなみに、アドレスバーでは実行できます。