Où est le goulot d'étranglement de la vitesse de navigation sur Raspberry Pi?

Sur un Model B 512 MB Pi avec Raspbian "wheezy", j'ai essayé Midori, Chromium et Iceweasel. Lorsque la page Web s'agrandit, le chargement est lent, même après l'avoir overclocké à 1 GHz. Sur un téléphone Android avec un processeur à 1 GHz, le chargement de la page Web semble beaucoup plus rapide.

Ce que je veux savoir, c'est où est le goulot d'étranglement dans le Pi? Est-ce le CPU, la taille de la RAM ou le serveur X non accéléré? Est-il possible pour le navigateur d'utiliser directement le GPU afin de l'accélérer?

C'est une combinaison du processeur ARM11 assez faible du Raspberry Pi et du serveur X non accéléré. Comme il n'est pas accéléré par le GPU, le CPU doit faire tout le rendu; sur quelque chose comme le cœur ARM11 dans le Pi, cela met beaucoup de pression supplémentaire sur un processeur déjà faible.

Pour l'anecdote, en regardant htoppendant que Midori sur le Pi charge un site Web lourd comme Facebook, j'ai vu le processus X prendre jusqu'à 25% du processeur.

Il n'est pas vraiment juste de comparer la puce de votre téléphone Android à la puce (même overclockée) du Pi. La puce 1 GHz de votre téléphone est probablement quelque chose comme un Cortex-A8 ou A9, qui utilise la version ARMv7 de l'architecture; ainsi, ils sont plus performants par cycle d'horloge que l'ARM11, qui utilise ARMv6.

C'est déjà la bonne réponse OMI, et ce que je propose ne fera probablement pas beaucoup de différence, mais il pourrait être utile de le savoir.

Si tout ce que vous voulez faire est d'exécuter le navigateur, vous n'avez pas besoin d'exécuter également un environnement de bureau. Créez un fichier qui ressemble à ceci $HOME/.xinitrc:

#!/bin/sh

midori

Si .xinitrc existe déjà, déplacez-le temporairement ou mettez-le en commentaire. Maintenant, startx(évidemment, vous ne devriez pas déjà y être - faites-le depuis la console sans que l'interface graphique ne fonctionne). Voila, vous avez juste le navigateur, pas de bureau.

Cela économise un peu de mémoire, bien que le navigateur soit de loin l'éléphant dans la pièce et que le serveur Xorg lui-même (qui fonctionne) soit plus grand qu'un lxde de base (qui ne fonctionne pas maintenant). Si vous avez tellement chargé dans la RAM que vous utilisez le swap, cela affectera les performances. Le Midori + X nu ci-dessus utilise <100 Mo de résident selon 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 Mo

C'est avec 4 onglets ouverts. Encore une fois, si vous les regardez et que votre RAM est presque pleine, c'est un problème de performances. Notez qu'il est normal d'utiliser un peu de swap même si le ram n'est pas plein, alors ne vous inquiétez pas à ce sujet - ces trucs échangés sont de faible priorité.

Une autre chose à penser, en termes de performances, est l'importance des tampons et du cache . Je ne les ai pas inclus dans le total, et notez que c'est en fait plus que la mémoire engagée (environ deux fois plus). C'est normal. Si vous remplissez la mémoire avec des éléments validés, le système utilisera simplement moins de cache et / ou le transférera pour permuter. Quoi qu'il en soit, cela va être une dégradation des performances car le cache est important (il n'est tout simplement pas vital ou immuable en termes de taille, donc ne fait pas partie de la statistique mem validée).

En d'autres termes, de manière optimale, vous souhaitez que votre RAM engagé ne représente pas plus de 75% de ce qui est disponible sur le pi et peut-être moins que cela. Si vous utilisez LXDE et commencez à ouvrir d'autres choses, vous pouvez rapidement commencer à vous en approcher.

Avertissement : Ce qui suit décrit l'utilisation de fonctionnalités expérimentales avec des effets douteux. Assurez-vous de tester les régressions introduites et les gains de performances réels.

Vous pouvez essayer certains des drapeaux de Google Chrome / Chromium sous under chrome://flagspour améliorer les performances de navigation (apparentes). Un article explique certains des indicateurs pertinents pour les performances . Je vais essayer d'en collecter ici:

Forcer l'accélération du GPU en activant la "Liste de rendu des logiciels écrasés" utilisera le GPU pour le rendu au prix d'artefacts possibles, même si le pilote n'est pas sur liste blanche. Je ne sais pas si cela fonctionne bien avec le GPU du Pi.

La composition GPU sur toutes les pages utilisera le GPU pour faire défiler toutes les couches. Les performances de défilement devraient donc s'améliorer sur les pages sans couches accélérées par le GPU.

Actualiser la fenêtre en mosaïque serait un autre indice. Il rendra les tuiles et les affichera dès qu'il sera prêt au lieu d'attendre la fin de la dernière. En effet, le rendu prendra plus de temps en raison de la surcharge introduite, mais le contenu apparaîtra plus rapidement.

Le rendu dans un thread séparé fera le rendu de manière asynchrone et gardera l'interface réactive. Vous pouvez faire défiler pendant le rendu de la page.

Désactiver GPU VSync mettra à jour le contenu rendu, que le moniteur l'ait déjà chargé ou non. Cela améliore la fréquence d'images au prix d'une présentation incohérente.

Après avoir activé / désactivé les commutateurs, vous devrez redémarrer Chrome / Chromium pour que le paramètre s'applique. Le bouton en bas de la page des drapeaux peut le faire pour vous.

Pour aller encore plus loin, les commutateurs de ligne de commande pourraient être utilisés pour optimiser Chrome / Chrome. Consultez la liste des commutateurs de ligne de commande Chromium pour une liste complète.

--default-tile-widthet --default-tile-heightpourrait être réglé pour correspondre à une fraction de la taille de l'écran afin d'accélérer le rendu initial de chaque page.