こんにちは HexletでJavaコースの作成に関与している私たちのチームは、非常に興味深いと思われる記事の翻訳を開始することにしました。 この問題に携わった後、Habréは「 モバイルWebアプリケーションがなぜそんなに遅いのか 」というタイトルのすばらしい記事の翻訳をまだ実行していないことがわかりました。 それが今日あなたの注意を引くのは、その部分の翻訳です。 この記事は新しいものではなく、Habréがその翻訳を満たしていないことはさらに驚くべきことでしたが、当然ながら多くのベンチマークは時代遅れですが、そのアイデアに（アイデアでは）関連しているようです。 Habraコミュニティが始まりを好んだら、2番目の部分を公開するとともに、非常に興味深いと思われ、Habréには掲載されなかった他の記事の翻訳の公開を開始します。



モバイルWebアプリケーションの動作が遅いと主張した前回の記事では、非常に多くの興味深い会話が行われました。 オンラインと実生活の両方で議論が行われましたが、残念ながら、それは私が望んでいるほど事実ではありませんでした。



この点に関して、この投稿では、根拠のない叫びを手配するだけでなく、この問題を議論するための真の証拠を提示します。 重要なポイントを見たり、専門家の意見を聞いたり、このトピックに関する明確なジャーナル記事を読んだりすることもできます。 この投稿には100を超える引用が含まれていますが、これは冗談ではありません。 この記事があなたを納得させること、または提示されたすべての情報に間違いがないこと（このサイズの記事では不可能です）を保証することはできませんが、これはモバイルの多くのiOS開発者の意見の最も包括的かつ詳細な分析であることを保証できますWebアプリケーションは動作し、近い将来、ゆっくり動作します。



警告：これは非常に退屈で長い記事で、ほぼ1万語です。 これがフォーマットです。 最近、私は人気のある記事よりも良い記事を好みます。 これは、私が以前に求めていたものを実践するだけでなく、良い記事を書くための私の試みです。事実に基づいた興味深い議論を奨励し、気の利いたコメントを控えます。



このトピックが際限なく議論されるという理由で、この記事を部分的に書きます（厳しいフレーズの交換という形で）。 これはハッキングされたトピックに関する別の記事ではありません。したがって、「いいえ、本当のWebアプリケーションはダメ！」「ダメ、ダメ」という精神で30秒のチャットを探しているなら、この記事はあなたには向いていません。 ウェブには、「ああ、やめて、息ができない、やめてください、意見が多く、事実がほとんどない」などの精神で、こうした議論がたくさんあります。 一方、私が知る限り、現時点では、この問題に関する詳細で有益で適切な議論を見つける場所はありません 。 これは非常に愚かなアイデアのように思えるかもしれませんが、この記事は、炎で満たされた完全に意味のない平凡な論争をすでに引き起こしているトピックを冷静に議論する私の試みを表しています。 私の立場はこれです。問題はむしろ、問題をより適切に議論できる人々は議論の対象ではなく議論に参加しないということです。 これが正しいかどうかはわかると思います。



したがって、すでに明らかなWeb革命の前夜に不運なプロプライエタリアプリケーションを書き続けている仲間の開発者にどのような狂気が生じているかを知りたい場合、または何か他のものを見つけ、このページをブックマークし、自分でコーヒーをれ、見つけてください自由な夜、快適な椅子に座って、今、私たちは議論の準備ができています。

短いレビュー

以前の投稿で、今日のモバイルWebアプリケーションは遅いというSunSpiderの例を論じました。

「もちろん、「Webアプリケーション」とは「1つまたは2つのボタンを備えたWebサイト」を意味する場合」、SunSpiderなどの惨めなパフォーマンステストをすべて地獄に送ることができます。 「高速ワードプロセッシング、写真編集、ローカルストレージ、画面間のアニメーション」を意味する場合、自殺していない限り、ARMのモバイルアプリケーションでこれを行うべきではありません。

この記事は本当に読む価値がありますが、パフォーマンステストを引き続き示します。







一般に、この比較テストは3つの観点から批判されています。

1. JSコードがネイティブコードよりも遅いことは秘密ではありません。CS1で、コンパイルされた言語、JIT言語、および解釈された言語を比較すると、誰もがそのことを知っています。 問題は、その遅い動作が作成するプログラムにどの程度影響するかであり、同様のパフォーマンステストではこの問題を何らかの方法で解決することはできません。
   
   
2. はい、JSはより遅く、それは重要ですが、そのパフォーマンスは絶えず成長しており、ある日、速度の差がすでに重要でないことに初めて気付くので、今すぐJSに投資を始​​めてください。
   
   
3. 私はPython / PHP / Rubyでサーバープログラムを書いていますが、あなたがそこで何を運転してもかまいません。 私のサーバーはモバイルデバイスよりも高速であることは知っていますが、実際には、 実際に解釈された言語を使用してX000ユーザーにサービスを提供することは難しくありませんが、高性能コンパイラーを使用して言語で1人のユーザーにサービスを提供する方法を想像できますか？ Jit？ それはどれくらい難しいのでしょうか？
   
   

この記事の3つの主張すべてに反論するという、かなり野心的な目標を設定しました。 はい、JSは低速で、本当に重要です。 いいえ、近い将来、目立って速くなることはありません。 いいえ、サーバープログラミングの経験では、「小規模から始めて」、モバイルアプリケーションのパフォーマンスを正しく説明するための適切な準備ができません。



主な問題は、このトピックに関するすべての記事で、 JSコードの動作が遅いことを示す数値がめったに与えられないこと、または何らかの有用な比較基準が与えられる ことです （ゆっくり... 何と比較して？ ）。 これを修正するために、この記事ではJavaScriptに対して1つではなく3つの同等のパフォーマンスを提供します。 したがって、私は「JSの遅い仕事」について「古い歌」に反論するだけでなく、それがどれほど遅いかを数字で示し、実際のプログラミングからの多くの指標と比較して、プラットフォームを選択する必要に直面したときに自分でできるようにします迅速に計算を行い、JavaScriptが特定の問題を解決するのに効果的かどうかを判断します。

これはすべて良いことですが、JSパフォーマンスとネイティブアプリケーションのパフォーマンスをどのように正確に比較するのでしょうか？

いい質問です。 それに答えるために、ベンチマークゲームから任意のパフォーマンステストを選択しました 。 次に、同じテストを実行する古いCプログラムを見つけました（新しいプログラムにはx86固有の詳細がたくさんあるため、古い）。 その後、テスト済みのiPhone 4SでNitroとLLVMを比較しました。 このコードはすべてGitHubにあります 。



これらはすべて非常にarbitrary意的ですが、実際に実行するコードはarbitrary意的です。 より良い実験が必要な場合は、実験してください。 LLVMとNitroを比較する他の実験はまだないため、これは私の実験です。



いずれにしても、この合成パフォーマンステストでは、LLVMは常にNitroより4.5倍高速です。







したがって、Nitro JSと比較してネイティブコードのプロセッサ制限機能がどれだけ高速であるかに興味がある場合、答えは「約5倍」になります。 この結果は一般に、x86 / GCC / V8のベンチマークゲームの結果と一致します。これによると 、GCC / x86は全体としてV8 / x86より2〜9倍高速です。 したがって、結果は真実に近いようで、ARMとx86のどちらを使用するかに依存しません。

しかし、パフォーマンスの1/5は十分ではありませんか？

x86で十分です。 実際、プロセッサはテーブルをどれだけレンダリングしますか？ そんなにない。 問題は、ARMがx86ではないことです。



GeekBenchによると 、最新のMBPモデルと最新のiPhoneモデルを比較すると10の係数が示されたため、すべてが正常で、テーブルはそれほど重くありません。 10％の生産性で作業できます。 そして、あなたはまだそれを5つに分けたいですか？ ブラボー、男！ これで、デスクトップコンピューターの2％のパフォーマンスが得られました（ユニットをランダムに操作しますが、1桁の規模で処理しています。大丈夫です）。



良いですが、ワープロは本当にどれほど難しいですか？ m68kなどのプロセッサでこれを実行し、別のプロセッサを追加することはできませんか？ さて、この質問には答えられます。 覚えていないかもしれませんが、Googleドキュメントをリアルタイムで操作することは、単なる起動機能ではありません。 2010年4月までに多くのことを書き直しました。 2010年4月のブラウザのパフォーマンスを見てみましょう。











このグラフから判断すると、iPhone 4Sは、Googleドキュメントとリアルタイムでやり取りする時代のWebブラウザーとまったく比較できないことは明らかです。 ただし、IE8と競合できます。



別の本格的なJavaScriptアプリケーション、Google Waveを検討してください。 Googleによると 、WaveはIE8の動作が遅すぎるため、IE8をサポートしていません。











^{（Internet ExplorerでGoogle Waveを使用するには、Google Chrome Frameブラウザー用のプラグインをインストールする必要があります。または、次のブラウザーのいずれかを使用できます。GoogleChrome、Safari 4、Firefox 3.5。ステップ）。}



これらのブラウザがiPhone 4Sよりも高速であることを確認してください。



サポートされているすべてのブラウザーで1000未満の結果が表示されるのがわかります。3800の結果を表示したブラウザーは、低速のため除外されますか？ iPhoneは2400の結果を表示します。IE8と同様に、Waveを実行するのに十分な速度ではありません。



明確にしましょう。 モバイルデバイスではリアルタイムで作業できますが、JavaScriptではできません。 ネイティブアプリケーションとWebアプリケーションのパフォーマンスの違いは、FireFoxとIE8のパフォーマンスの違いに匹敵します。 これは真面目な仕事には違いすぎる 。

しかし、V8 /モダンJSのパフォーマンスはCとほぼ同じくらい良いと思いました！

それはすべて「ほぼ」の意味に依存します。 Cプログラムを10ミリ秒で実行する場合、JavaScriptプログラムの50ミリ秒の速度はCの速度と「ほぼ」等しくなります。Cプログラムを10秒で実行する場合、ほとんどの普通の人のJavaScriptプログラムの50秒は明らかにCとほぼ等しい速度になります。

ハードウェアの側面

それでも、 x86は5倍の係数で問題ありません。これは、主にx86がARMよりも10倍速いためです。 操縦の余地は十分にあります。 このソリューションは、ARMを10倍だけ高速化することを明確に意図しているため、x86に匹敵し、デスクトップコンピューターでJSのようなパフォーマンスを追加の労力なしで実現できます。



これが機能するかどうかは、3オンスのバッテリーでチップを充電する試みに関するムーアの法則に対するあなたの信念に依存します。 私はハードウェアエンジニアではありませんが、以前は大規模な半導体製造会社で働いていましたが、従業員は現在、生産性は主に技術プロセス （つまり、ナノメートルで測定される値）に依存していると言いました。 iPhone 5の印象的なパフォーマンスは、主に技術プロセスの45 nmから32 nmへの減少、つまり約3分の1の減少に関連していますが、これを繰り返すには、製造プロセスを22 nmに縮小する必要があります。



参考のために：Intelの22nm x86 Atom Bay Trailバージョンは現在存在しません 。 標準バージョンは22 nmのスケールでは機能しなかったため、Intelはまったく新しい種類の導体を発明する必要がありました。 彼らはARMライセンスを販売すると思いますか？ もう一度考えてください。 わずか22nmの集積回路企業のみが世界で真剣に構築される予定であり、それらのほとんどはIntelによって管理されています。



実際、ARMは製造プロセスを28 nm程度に減らすよう努力しているようですが（A7を参照）、Intelは22 nm、場合によっては20 nmを目指しています。 ハードウェアの側面だけを考慮すると、x86クラスのパフォーマンスを備えたx86チップは、x86クラスのパフォーマンスを備えたARMチップを削減する機会が生じるよりもはるかに早くスマートフォンで使用される可能性が高いようです。



メールを送ってくれた元インテルエンジニアからのメモ：

「私はモバイルデバイス用のマイクロプロセッサ製品のラインで働き、その後Atomsで働いた元インテルエンジニアです。 私の信じられないほど偏った意見では、ARMよりも大きなカーネルの「機能のセット」を備えた電話にx86をインストールして、パフォーマンスでx86に追いつき、これらの機能をゼロから開発する方が簡単かもしれません。」

私にメールを送ったロボティクスの元エンジニアからのメモ：

「彼らは生産性をわずかに向上させること、そしてインテルが数年以内にモバイルデバイス向けのより高速なプロセッサを搭載する可能性があることは絶対に正しいです。 実際、現在、モバイルプロセッサは3 GHzに達したときにデスクトッププロセッサと同じ制限があります。クロック周波数をさらに上げることは、電力を大幅に増加させなければ実用的ではありません。 これは、次のプロセスノードにも当てはまりますが、IPCをわずかに（おそらく10〜20％）増やすことができるはずです。 この制限に直面すると、デスクトップコンピューター用のデュアルコアおよびクアッドコアプロセッサの製造が開始されましたが、チップ上のモバイルシステムは既にデュアルコアおよびクアッドコアであるため、高速化は容易ではありません。

したがって、最終的にはムーアの法則は真実かもしれませんが、x86への移行にはモバイルエコシステム全体が必要です。 これは不可能だと言うことではなく、 すでに行われています 。 確かに、これは年間販売が約100万台に達し、今では四半期ごとに 6,200万台が販売された時代でした。 これは、古いアーキテクチャを約60％の速度で模倣できる既製の仮想化環境を使用して行われました。 一方、最適化された（O3）コードに対する最新の仮想化仮想検索エンジンのパフォーマンスは27％に近づいています。



JavaScriptが最終的にこれに到達すると思われる場合は、ハードウェアのアップグレードが最も効果的な方法になります。 Intelは5年後に（おそらく）実行可能なチップを搭載し、Appleはコンセプトを変更する（おそらくない）か、ARMは次の10年でゲームを終了します（10人のハードウェアエンジニアに相談すると、そのようなオプションの可能性について10の異なる意見が得られます）。 しかし、10年は成功するプロジェクトにとって長い時間です。



ハードウェアに関する私の知識がここで終わるのではないかと思います。 私があなたに伝えることができることは一つだけです。もしARMが今後5年間でx86とのギャップを埋めることを信じたいなら、まずARMまたはx86で働いている人（つまり、本当に知識がある人）を見つけて彼が同意する必要がありますあなたによって。 この記事を書くために、私は多くの資格のあるエンジニアと相談しましたが、全員がこの立場を公式に表明することを拒否したため、良いことは何もないようです。

プログラムの側面

多くの有能なソフトウェアエンジニアがここで立ち止まっています。 彼らはこのように考えています：JavaScriptはより高速になり、加速し続けます！



この文の最初の部分は真実です。 JavaScriptははるかに高速になりました。 それにもかかわらず、すでにピークに達しており、将来、その速度は大幅に増加しません。



なんで？ 第一に、JavaScriptの歴史の改善のほとんどは、実際にはハードウェアにあります。 ジェフ・アトウッドが書いていることは次のとおりです

「JavaScriptのパフォーマンスは1996年から2006年の間に大幅に改善されたことがわかりました。 Web 2.0がJavaScriptの上に構築されているという事実は、主にムーアの法則による決定的なパフォーマンスの改善により可能になりました。

JSのアクセラレーションを全体としてハードウェアに接続する場合、JSのパフォーマンス（ハードウェア） を改善することは、将来のプログラムパフォーマンスを改善するための前提条件ではありません 。 そのため、JSが加速すると信じたいのであれば、今日では機器の加速が原因である可能性が最も高くなります。これは歴史的な傾向からも明らかです。



JIT、V8、Nitro / SFX、TraceMonkey / IonMonkey、Chakraなどはどうですか？ まあ、リリースの時点では、それらはあなたが思うほど重要ではありませんが、重要なものでした。 V8は2008年9月にリリースされました。 同じ頃、Firefox 3.0.3のコピーを掘りました。







誤解しないでください。9倍のパフォーマンスの向上は無視できません。結局のところ、この数はARMとx86の差にほぼ等しいです。 したがって、Chrome 8とChrome 26のパフォーマンスの違いは同じレベルのままです。2008年以降、特に重要なことは何も起きていないためです。 他のブラウザメーカーはそれを補っています（一部はより高速で、一部はより低速です）が、それ以来プロセッサコード自体の速度を実際に向上させた人はいません。

JavaScriptのパフォーマンスは向上していますか？

これが私のMac上のChrome v8 （2010年12月にまだ動作する最も古いバージョン）であり、ここにv26です。









違いが見えませんか？ これは彼女がそこにいないからです。 最近、プロセッサによって制限されたJavaScriptでは、特に重要なことは起こりませんでした。



Webが2010年よりも高速に見える場合、これはおそらく、より高速なコンピューターで作業しているという事実によるものであり、Chromeの改善はそれとは何の関係もありません。



ご注意 一部の賢明な人々は、最近、SunSpiderはパフォーマンスの良いベンチマークではないと指摘しています（そして、彼らは関連する数値を提供することを拒否しました）。 意味のある議論を始めるために、古いバージョンのChromeでOctane（Googleのテスト）を実行しましたが、改善が見られました。









私の意見では、この期間に得られたパフォーマンスの改善は、JSが予見可能な期間のギャップを埋めているという声明の十分な確認ではありません。 ただし、JavaScriptで何かが発生し、プロセッサによって制限されるため、このケースを過大評価したことを認めなければなりません。 それにもかかわらず、私にとって、これらの数字は大きな仮説を裏付けています。これらの改善は、予見可能な将来においてネイティブコードとのギャップを埋めることができる量ではありません。 LLVMと競合するには、すべてを2〜9倍改善する必要があります。 これらの改善は良いですが、その程度ではありません。 メモの終わり。



実際、60年前にJavaScriptでJITを使用するというアイデアが生まれました。 その後、60年の研究と、すべてのプログラミング言語の文字通り数千の実装が、それが良いアイデアであることを証明するために続きました。 これを行ったので、60年前にアイデアを使い果たしました。 すべての友人、ショーは終わりました。 おそらく、今後60年間で別の良いアイデアを思いつくことができるでしょう。

しかし、Safariは以前よりも速いように見えますか？

これが本当なら、なぜ私たちはJavaScriptのすべての素晴らしいパフォーマンスの改善について常に聞いているのですか？ ほぼ毎週、誰かが何らかのテストで巨大な加速を宣伝しています。 ここで、AppleはJSBenchで驚異的な3.8倍の加速を主張しています。











では、Safari 7は他のブラウザーよりも3.8倍高速ですか？



おそらくAppleの利便性のために、このバージョンのSafariに関する情報は公開されていないため、Safariのパフォーマンスに関する独立したデータを公開することはできません。 それにもかかわらず、公に入手可能な情報のみに基づいて、この声明についていくつかの点を述べさせてください。



まず、AppleがSunSpiderのような従来のテストレポートよりもオープンなJSBenchレポートでより良い結果を報告するという事実に興味がありました。 JavaScriptの作成者であるBrendan Eichなど、JSBenchの背後には興味深い人々がいますが、従来のテストとは異なり、JSBenchは整数またはそのようなものが決定的な役割を果たすプログラムを作成しません。 代わりに、JSBenchはAmazon、Facebook、Twitterが提供するすべてのものを自動的に取得し、それらすべてからテストを作成します。 （率直に言って）ほとんどの人がFacebookにアクセスするために使用するWebブラウザーを作成している場合、Facebook専用のテストを行うことがどれほど便利か想像できます。 一方、スプレッドシートプログラム、ゲーム、または画像フィルタリングアプリケーションを作成している場合、整数演算とmd5ハッシュを使用した従来のテストは、Facebookの分析コードの速度を観察するよりもはるかに有用であると思われます。



別の重要な事実は、Appleによると、SunSpiderのパフォーマンスを向上させることは、他の何かを向上させることを必ずしも意味しないということです。 Appleの推奨テストを示す同じドキュメントで、Eichと他の人は次のように書いています。

「この図は、SunSpiderによると、Firefoxバージョン3.6のパフォーマンスがバージョン1.5に比べて13倍向上したことを明確に示しています。 それにもかかわらず、Amazonの改善点を見ると、3倍ほど控えめに見えます。 さらに興味深いことに、過去2年間でAmazonの改善は横ばいになりました。 どうやら、Sun Spiderでうまく機能するいくつかの最適化は、Amazonでは効果がありません。

同じドキュメントで、 JavaScript の作成者とMozillaの主要なアーキテクトの1人は、過去2年間にAmazonのJavaScriptサイトのパフォーマンスに何も起こらず、信じられないほどエキサイティングなことは何もなかったことを公然と認めています。 これは、マーケティング担当者が製品を何年も強制することを示唆しています。



トピックを続けると、彼らは本質的に、Amazonパフォーマンステストは、SunSpiderのパフォーマンステストよりもAmazonのパフォーマンスを予測するための優れたツールであると主張します[明らかに...]。したがって、AmazonにアクセスするWebブラウザーに適しています。 ただし、これだけでは写真処理アプリケーションの作成には役立ちません。



しかし、いずれにせよ、オープンな情報に頼って、パフォーマンスの3.8倍の向上に関するAppleの声明は、必ずしもあなたにとって有益なものを意味するとは言えません。 また、AppleのChromeに対する優位性に反論するテストがあった場合、それらを公開することは許可されないと言えます。



このセクションを次の結論で締めくくりましょう。誰かが自分のWebブラウザーが高速であることを示すグラフを持っている場合、これはJS全体が高速になっているという意味ではありません。



記事がやがて気に入ったのと同じくらいあなたが記事を好きになることを本当に願っています。 もしそうなら、すぐにあなたは翻訳の第二の部分を見つけるでしょう。