¿Dónde está el cuello de botella de la velocidad de navegación web en Raspberry Pi?

En un modelo B de 512 MB Pi con Raspbian "wheezy", he probado Midori, Chromium y Iceweasel. Cuando la página web se hace más grande, la carga es lenta, incluso después de que la overclockeé a 1 GHz. En un teléfono Android con una CPU de 1 GHz, la carga de la página web parece mucho más rápida.

Lo que quiero saber es, ¿dónde está el cuello de botella en el Pi? ¿Es la CPU, o el tamaño de la RAM, o el servidor X no acelerado? ¿Es posible que el navegador use GPU directamente para acelerarlo?

Es una combinación de la CPU ARM11 bastante débil de la Raspberry Pi y el servidor X no acelerado. Como la GPU no la acelera, la CPU tiene que hacer todo el renderizado; en algo como el núcleo ARM11 en el Pi, esto pone mucha tensión extra en una CPU ya débil.

Como anécdota, mientras miro htopmientras Midori en el Pi carga un sitio web pesado como Facebook, he visto que el proceso X toma hasta el 25% de la CPU.

No es realmente justo comparar el chip en su teléfono Android con el chip (incluso overclockeado) en el Pi. El chip de 1 GHz en su teléfono es probablemente algo así como un Cortex-A8 o A9, que utilizan la versión ARMv7 de la arquitectura; por lo tanto, tienen un mayor rendimiento por ciclo de reloj que el ARM11, que usa ARMv6.

Esta es la respuesta correcta de la OMI, y lo que sugiero probablemente no haga mucha diferencia, pero podría ser útil saberlo.

Si todo lo que quiere hacer es ejecutar el navegador, no tiene que ejecutar también un entorno de escritorio. Cree un archivo que se vea así como $HOME/.xinitrc:

#!/bin/sh

midori

Si .xinitrc ya existe, muévalo temporalmente o comente cualquier otra cosa. Ahora, startx(obviamente, ya no deberías estar en él; hazlo desde la consola sin ejecutar la GUI) Voila, solo tienes el navegador, no escritorio

Eso ahorra un poquito de memoria, aunque el navegador es, con mucho, el elefante en la habitación y el servidor Xorg en sí (que se está ejecutando) es más grande que un lxde básico (que ahora no se está ejecutando). Si ha cargado tanto en la RAM que está utilizando el intercambio, eso afectará el rendimiento. El midori + bare X anterior utiliza <100 MB de residentes según 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

Eso es con 4 pestañas abiertas. Nuevamente, si observa estos y ve que su RAM está casi llena, eso es un problema de rendimiento. Tenga en cuenta que es normal usar un poco de intercambio, incluso si el carnero no está lleno, así que no se preocupe por eso, ese material intercambiado es de baja prioridad.

Algo más en lo que pensar, en cuanto al rendimiento, es la importancia de los buffers y el caché . No incluí estos en el total, y note que en realidad es más que la memoria comprometida (aproximadamente el doble). Eso es normal. Si llena la memoria con cosas comprometidas, el sistema solo usará menos caché y / o lo transferirá para intercambiar. De cualquier manera, eso va a ser una degradación del rendimiento porque la memoria caché es importante (simplemente no es vital ni inmutable en cuanto al tamaño, por lo que no forma parte de la estadística comprometida).

En otras palabras, de manera óptima, desea que su memoria RAM comprometida no sea más del 75% de lo que está disponible en el pi y tal vez menos que eso. Si usa LXDE y comienza a abrir otras cosas, puede comenzar a abordarlo rápidamente.

Descargo de responsabilidad : A continuación se describe el uso de características experimentales con efectos dudosos. Asegúrese de probar las regresiones introducidas y las ganancias reales de rendimiento.

Puede probar algunas de las banderas de Google Chrome / Chromium debajo chrome://flagspara mejorar el rendimiento (aparente) de navegación. Hay un artículo que explica algunos de los indicadores relevantes para el rendimiento . Trataré de recoger algunos aquí:

Al forzar la aceleración de la GPU al habilitar "Sobrescribir lista de renderizado de software", se utilizará la GPU para renderizar a costa de posibles artefactos, incluso si el controlador no está en la lista blanca. Sin embargo, no sé qué tan bien funciona esto con la GPU de Pi.

La composición de GPU en todas las páginas usará la GPU para desplazar todas las capas. Por lo tanto, el rendimiento de desplazamiento debería mejorar en páginas sin capas aceleradas por GPU.

Actualizar ventana en mosaico sería otra pista. Representará los mosaicos y mostrará cada uno tan pronto como esté listo en lugar de esperar a que termine el último. En efecto, la representación llevará más tiempo debido a la sobrecarga introducida, pero el contenido aparecerá más rápido.

La representación en un hilo separado hará la representación de forma asincrónica y mantendrá la interfaz receptiva. Puede desplazarse mientras la página aún se está procesando.

Desactivar GPU VSync actualizará los contenidos renderizados independientemente de si el monitor ya los ha cargado. Esto mejora la velocidad de fotogramas a costa de una presentación inconsistente.

Después de habilitar / deshabilitar cualquier interruptor, deberá reiniciar Chrome / Chromium para que se aplique la configuración. El botón en la parte inferior de la página de banderas puede hacerlo por usted.

Yendo aún más lejos, los interruptores de línea de comando podrían usarse para optimizar Chrome / Chromium. Consulte la Lista de interruptores de línea de comandos de Chromium para obtener una lista completa.

--default-tile-widthy --default-tile-heightse puede configurar para que coincida con una fracción del tamaño de la pantalla para acelerar la representación inicial de cada página.