Onde está o gargalo da velocidade de navegação na Web no raspberry pi?

Em um Pi Modelo 512 MB com Raspbian “wheezy”, tentei Midori, Chromium e Iceweasel. Quando a página da Web aumenta, o carregamento é lento, mesmo depois de eu ter feito o overclock para 1 GHz. Em um telefone Android com uma CPU de 1 GHz, o carregamento da página da Web parece muito mais rápido.

O que eu quero saber é: onde está o gargalo no Pi? É o tamanho da CPU, RAM ou servidor X não acelerado? É possível que o navegador use a GPU diretamente para acelerar?

É uma combinação da CPU ARM11 bastante fraca do Raspberry Pi e do servidor X não acelerado. Como não é acelerado pela GPU, a CPU precisa fazer toda a renderização; em algo como o núcleo ARM11 no Pi, isso coloca muita pressão extra em uma CPU já fraca.

Curiosamente, enquanto assistia o htopMidori no Pi carregar um site pesado como o Facebook, vi o processo X ocupar até 25% da CPU.

Não é realmente justo comparar o chip do seu telefone Android com o chip (mesmo com overclock) no Pi. O chip de 1 GHz no seu telefone é provavelmente algo como um Cortex-A8 ou A9, que usa a versão ARMv7 da arquitetura; portanto, eles têm desempenho mais alto por ciclo de clock do que o ARM11, que usa o ARMv6.

Essa já é a resposta correta da IMO, e o que estou sugerindo provavelmente não fará muita diferença, mas pode ser útil saber.

Se tudo o que você deseja fazer é executar o navegador, você também não precisará executar um ambiente de área de trabalho. Crie um arquivo parecido com o seguinte $HOME/.xinitrc:

#!/bin/sh

midori

Se o .xinitrc já existir, mova-o temporariamente ou comente qualquer outra coisa. Agora startx(obviamente, você ainda não deveria estar nele - faça isso no console sem a GUI em execução). Voila, você tem apenas o navegador, sem desktop.

Isso economiza um pouquinho de memória, embora o navegador seja de longe o elefante na sala e o próprio servidor Xorg (em execução) seja maior que um lxde básico (que agora não está em execução). Se você tem tanta carga na RAM que está usando swap, isso afetará o desempenho. O midori + X vazio acima usa <100 MB residente de acordo com 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

Isso é com 4 abas abertas. Novamente, se você olhar para eles e ver que a RAM está quase cheia, isso é um problema de desempenho. Observe que é normal usar um pouco de troca, mesmo que o ram não esteja cheio, então não se preocupe com isso - esse material trocado é de baixa prioridade.

Algo mais a se pensar, em termos de desempenho, é o significado de buffers e cache . Eu não os incluí no total e observe que na verdade é mais do que a memória confirmada (cerca do dobro). Isso é normal. Se você preencher a memória com material comprometido, o sistema usará apenas menos cache e / ou a transferirá para troca. De qualquer forma, isso será uma degradação do desempenho, porque o cache é importante (não é apenas um tamanho vital ou imutável, portanto, não faz parte do status da memória confirmada).

Em outras palavras, de maneira ideal, você deseja que o seu carneiro comprometido não ultrapasse 75% do que está disponível no pi e talvez menos que isso. Se você usa o LXDE e começa a abrir outras coisas, pode começar rapidamente a abordar isso.

Isenção de responsabilidade : O seguinte descreve o uso de recursos experimentais com efeitos duvidosos. Certifique-se de testar as regressões introduzidas e os ganhos reais de desempenho.

Você pode experimentar algumas das bandeiras do Google Chrome / Chromium abaixo de chrome://flagspara melhorar o (aparente) desempenho da navegação. Há um artigo explicando algumas das sinalizações relevantes para o desempenho . Vou tentar coletar alguns aqui:

Forçar a aceleração da GPU ativando "Substituir lista de renderização de software" usará a GPU para renderizar ao custo de possíveis artefatos, mesmo se o driver não estiver na lista de permissões. Mas não sei o quanto isso funciona com a GPU do Pi.

A composição da GPU em todas as páginas usará a GPU para rolar todas as camadas. Portanto, o desempenho da rolagem deve melhorar em páginas sem camadas aceleradas por GPU.

Atualizar a janela em sentido contrário seria outra dica. Ele renderizará blocos e exibirá cada um assim que estiver pronto, em vez de esperar o último terminar. Com efeito, a renderização levará mais tempo devido à sobrecarga introduzida, mas o conteúdo aparecerá mais rápido.

A renderização em thread separado fará a renderização assincronamente e manterá a interface responsiva. Você pode rolar enquanto a página ainda está sendo renderizada.

Desativar GPU O VSync atualizará o conteúdo renderizado, independentemente de o monitor ainda os ter carregado. Isso melhora a taxa de quadros ao custo de uma apresentação inconsistente.

Depois de ativar / desativar qualquer opção, você precisará reiniciar o Chrome / Chromium para que a configuração seja aplicada. O botão na parte inferior da página de sinalização pode fazer isso por você.

Indo além, as opções de linha de comando podem ser usadas para otimizar o Chrome / Chromium. Consulte a Lista de opções de linha de comando do Chromium para obter uma lista completa.

--default-tile-widthe --default-tile-heightpode ser configurado para corresponder a uma fração do tamanho da tela para acelerar a renderização inicial de cada página.