Wo ist der Engpass der Web-Browsing-Geschwindigkeit auf Himbeer-Pi?

Auf einem Model B 512 MB Pi mit Raspbian „Wheezy“ habe ich Midori, Chrom und Iceweasel ausprobiert. Wenn die Webseite größer wird, wird sie langsam geladen, selbst nachdem ich sie auf 1 GHz übertaktet habe. Auf einem Android-Handy mit einer 1-GHz-CPU scheint das Laden der Webseite viel schneller zu sein.

Was ich wissen möchte ist, wo ist der Engpass im Pi? Handelt es sich um die CPU- oder RAM-Größe oder um einen nicht beschleunigten X-Server? Kann der Browser die GPU direkt verwenden, um sie zu beschleunigen?

Es ist eine Kombination aus der ziemlich schwachen ARM11-CPU des Raspberry Pi und dem nicht beschleunigten X-Server. Da es von der GPU nicht beschleunigt wird, muss die CPU das gesamte Rendering ausführen. Auf so etwas wie dem ARM11-Kern im Pi bedeutet dies eine zusätzliche Belastung für eine ohnehin schon schwache CPU.

Anekdotisch gesehen, während htopMidori auf dem Pi eine schwere Website wie Facebook lädt, habe ich gesehen, dass der X-Prozess bis zu 25% der CPU einnimmt.

Es ist nicht wirklich fair, den Chip in Ihrem Android-Handy mit dem (sogar übertakteten) Chip im Pi zu vergleichen. Der 1-GHz-Chip in Ihrem Telefon ist wahrscheinlich so etwas wie ein Cortex-A8 oder A9, der die ARMv7-Version der Architektur verwendet. Daher sind sie pro Taktzyklus leistungsstärker als der ARM11, der ARMv6 verwendet.

Dies ist bereits die richtige Antwort IMO, und was ich vorschlage, wird wahrscheinlich keinen großen Unterschied machen, aber es könnte nützlich sein zu wissen.

Wenn Sie nur den Browser ausführen möchten, müssen Sie auch keine Desktop-Umgebung ausführen. Erstellen Sie eine Datei, die so aussieht $HOME/.xinitrc:

#!/bin/sh

midori

Wenn .xinitrc bereits vorhanden ist, verschieben Sie es vorübergehend oder kommentieren Sie etwas anderes aus. Jetzt startx(offensichtlich sollten Sie noch nicht dabei sein - tun Sie dies von der Konsole aus, ohne dass die GUI ausgeführt wird). Voila, du hast nur den Browser, keinen Desktop.

Das spart ein bisschen Speicher, obwohl der Browser bei weitem der Elefant im Raum ist und der Xorg-Server selbst (der läuft) größer ist als eine einfache LXDE (die jetzt nicht läuft). Wenn Sie so viel RAM geladen haben, dass Sie Swap verwenden, wirkt sich dies auf die Leistung aus. Das obige midori + bare X verwendet <100 MB resident gemäß 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

Das ist mit 4 Registerkarten offen. Wenn Sie sich diese ansehen und feststellen, dass Ihr RAM nahezu voll ist, ist dies wiederum ein Leistungsproblem. Beachten Sie, dass es normal ist, ein wenig zu tauschen, auch wenn der RAM nicht voll ist. Machen Sie sich deshalb keine Sorgen - das getauschte Zeug hat eine niedrige Priorität.

Weitere Überlegungen zur Leistung sind die Bedeutung von Puffern und Cache . Ich habe diese nicht in die Gesamtsumme einbezogen, und es ist tatsächlich mehr als der festgeschriebene Speicher (ungefähr doppelt so viel). Das ist normal. Wenn Sie den Speicher mit zugesicherten Daten füllen, verbraucht das System nur weniger Cache und / oder überträgt sie zum Auslagern. So oder so, dass eine Leistungsverschlechterung sein wird , da der Cache ist wichtig (es ist einfach nicht vital oder unveränderliche Größe weist, also nicht Teil des engagierten mem stat).

Mit anderen Worten, Sie möchten optimalerweise, dass Ihr festgeschriebener RAM nicht mehr als 75% der auf dem Pi verfügbaren Daten und möglicherweise weniger davon enthält. Wenn Sie LXDE verwenden und damit beginnen, andere Dinge zu öffnen, können Sie schnell beginnen, sich dem anzunähern.

Haftungsausschluss : Im Folgenden wird die Verwendung von experimentellen Funktionen mit zweifelhaften Effekten beschrieben. Stellen Sie sicher, dass Sie auf eingeführte Regressionen und tatsächliche Leistungssteigerungen prüfen.

Probieren Sie einige der Google Chrome- / Chromium- Flags unter aus chrome://flags, um die (scheinbare) Browsing-Leistung zu verbessern. In einem Artikel werden einige der für die Leistung relevanten Flags erläutert . Ich werde versuchen, hier einige zu sammeln:

Durch Erzwingen der GPU-Beschleunigung durch Aktivieren von "Software-Rendering-Liste überschreiben" wird die GPU zum Rendern auf Kosten möglicher Artefakte verwendet, auch wenn der Treiber nicht auf der Whitelist steht. Ich weiß allerdings nicht, wie gut das mit der GPU des Pi funktioniert.

Beim Zusammenstellen von GPUs auf allen Seiten wird die GPU zum Scrollen aller Ebenen verwendet. Daher sollte sich die Bildlaufleistung auf Seiten ohne GPU-beschleunigte Ebenen verbessern.

Fenster nebeneinander aktualisieren wäre ein weiterer Hinweis. Sobald es fertig ist, werden Kacheln gerendert und angezeigt, anstatt darauf zu warten, dass die letzte fertig ist. Tatsächlich dauert das Rendern aufgrund des eingeführten Overheads länger, der Inhalt wird jedoch schneller angezeigt.

Beim Rendern in einem separaten Thread wird das Rendern asynchron ausgeführt und die Benutzeroberfläche bleibt ansprechbar. Sie können einen Bildlauf durchführen, während die Seite noch gerendert wird.

GPU deaktivieren VSync aktualisiert die gerenderten Inhalte unabhängig davon, ob der Monitor sie noch geladen hat. Dies verbessert die Bildrate auf Kosten einer inkonsistenten Darstellung.

Nach dem Aktivieren / Deaktivieren von Schaltern müssen Sie Chrome / Chromium neu starten, damit die Einstellung angewendet wird. Die Schaltfläche am unteren Rand der Flags-Seite kann das für Sie tun.

Geht man noch weiter, Befehlszeilenschalter verwendet werden könnte Chrome / Chromium zu optimieren. Eine vollständige Liste finden Sie in der Liste der Chromium-Befehlszeilenoptionen .

--default-tile-widthund --default-tile-heightkönnte so eingestellt werden, dass sie einem Bruchteil der Bildschirmgröße entspricht, um das anfängliche Rendern jeder Seite zu beschleunigen.