ラズベリーパイのウェブ閲覧速度のボトルネックはどこですか？

Raspbian「wheezy」を搭載したモデルB 512 MB Piで、Midori、Chromium、Iceweaselを試しました。Webページが大きくなると、1 GHzにオーバークロックした後でも読み込みが遅くなります。1 GHz CPUを搭載したAndroidスマートフォンでは、Webページの読み込みがはるかに高速になります。

私が知りたいのは、Piのボトルネックはどこですか？CPU、RAMサイズ、または高速化されていないXサーバーですか？ブラウザがGPUを直接使用して高速化することは可能ですか？

これは、Raspberry Piのかなり弱いARM11 CPUと高速化されていないXサーバーの組み合わせです。GPUによって加速されないため、CPUはすべてのレンダリングを行う必要があります。PiのARM11コアのようなものでは、これはすでに弱いCPUに多くの余分な負担をかけます。

逸話的htopに、PiのMidoriがFacebookのような重いWebサイトをロードしているのを見ていると、XプロセスがCPUの最大25％を占めるのを見ました。

Android搭載端末のチップと、Piのチップ（オーバークロックされている場合でも）を比較するのは、あまり公平ではありません。電話機の1 GHzチップは、おそらくCortex-A8またはA9のようなもので、ARMv7バージョンのアーキテクチャを使用しています。したがって、ARMv6を使用するARM11よりもクロックサイクルあたりのパフォーマンスが高くなります。

これはすでにIMOの正しい答えであり、私が提案していることはおそらく大きな違いにはならないでしょうが、知っておくと役立つかもしれません。

ブラウザを実行するだけであれば、デスクトップ環境も実行する必要はありません。次のようなファイルを作成します$HOME/.xinitrc。

#!/bin/sh

midori

.xinitrcが既に存在する場合は、一時的に移動するか、他のものをコメントアウトします。今、startx（明らかに、あなたは既にそこにいるべきではありません-GUIを実行せずにコンソールからこれを行います）。出来上がり、あなただけのブラウザがあり、デスクトップはありません。

ブラウザーは部屋の象であり、Xorgサーバー自体（実行中）は基本的な lxde（現在は実行されていません）よりも大きくなりますが、これによりメモリがわずかに節約されます。スワップを使用しているほど多くのRAMをロードしている場合、パフォーマンスに影響します。上記のmidori + bare Xは、次のように<100 MBの常駐を使用しfreeます。

             total       used       free     shared    buffers     cached
Mem:        448708     242604     206104          0      82660     105156
-/+ buffers/cache:      54788     393920
Swap:       102396          0     102396

448708-393920 = 54788/1024 = 53.5 MB

4つのタブが開いています。繰り返しますが、これらを見て、RAMがほぼ一杯になっている場合は、パフォーマンスの問題です。ラムであっても、スワップのビットを使用することが正常であることを注意しませスワップのものが低い優先順位であること- 、フル心配そうではありません。

パフォーマンスに関して賢明なことは、バッファとキャッシュの重要性です。これらは合計に含めませんでしたが、実際にはコミットされたメモリよりも多いことに注意してください（約2倍）。それは正常です。コミットされたものでメモリがいっぱいになると、システムは使用するキャッシュが少なくなり、スワップに転送されます。いずれにせよ、キャッシュは重要であるため、パフォーマンスの低下になります（サイズが重要でも不変でもないため、コミットされたmem statの一部ではありません）。

言い換えれば、コミットされたram がpiで利用できるものの75％以下で、おそらくそれよりも小さくすることが最適です。LXDEを使用して他のものを開くと、すぐにそれにアプローチし始めるかもしれません。

免責事項：以下では、疑わしい効果を伴う実験的機能の使用について説明します。導入されたリグレッションと実際のパフォーマンスの向上をテストしてください。

（見かけの）ブラウジングパフォーマンスを向上させるために、Google Chrome / Chromiumのいくつかのフラグを下で試すことができchrome://flagsます。パフォーマンスに関連するフラグのいくつかを説明する記事があります。私はここでいくつかを収集しようとします：

「Overrrite Software Rendering List」を有効にしてGPUアクセラレーションを強制すると、ドライバーがホワイトリストに登録されていなくても、可能なアーティファクトを犠牲にしてレンダリングにGPUが使用されます。しかし、これがPiのGPUでどのように機能するかはわかりません。

すべてのページでのGPU合成では、GPUを使用してすべてのレイヤーをスクロールします。そのため、GPUアクセラレーションレイヤーのないページでのスクロールパフォーマンスが向上するはずです。

ウィンドウをタイルごとに更新することもヒントです。最後のタイルが終了するのを待つ代わりに、準備ができ次第、タイルをレンダリングし、それぞれを表示します。実際には、オーバーヘッドが発生するためレンダリングに時間がかかりますが、コンテンツはより速く表示されます。

別のスレッドでレンダリングすると、レンダリングが非同期で行われ、インターフェイスの応答性が維持されます。ページのレンダリング中にスクロールできます。

GPU VSyncを無効にすると、モニターがそれらをまだロードしているかどうかに関係なく、レンダリングされたコンテンツが更新されます。これにより、一貫性のない表示を犠牲にしてフレームレートが向上します。

スイッチを有効/無効にした後、設定を適用するにはChrome / Chromiumを再起動する必要があります。フラグページの下部にあるボタンを使用して、これを実行できます。

さらに進むと、コマンドラインスイッチを使用してChrome / Chromiumを最適化できます。完全なリストについては、Chromiumコマンドラインスイッチのリストを参照してください。

--default-tile-widthそして--default-tile-height、各ページの初期レンダリングをスピードアップするために画面サイズの割合と一致するように設定することができます。