Where is the bottleneck of web browse speed on raspberry pi?

Question

On a Model B 512 MB Pi with Raspbian “wheezy”, I have tried Midori, Chromium and Iceweasel. When the web page gets larger, loading is slow, even after I overclocked it to 1 GHz. On an Android phone with a 1 GHz CPU, the web page loading seems much faster.

What I want to know is, where's the bottleneck in the Pi? Is it the CPU, or RAM size, or unaccelerated X server? Is it possible for the browser to use GPU directly in order to speed it up?

Answer 1

It's a combination of the Raspberry Pi's fairly weak ARM11 CPU and the unaccelerated X server. Since it's not accelerated by the GPU, the CPU has to do all the rendering; on something like the ARM11 core in the Pi, this puts a lot of extra strain on an already weak CPU.

Anecdotally, while watching htop while Midori on the Pi loads a heavy website like Facebook, I've seen the X process take up to 25% of the CPU.

It's not really fair to compare the chip in your Android phone to the chip (even overclocked) in the Pi. The 1 GHz chip in your phone is probably something like a Cortex-A8 or A9, which use the ARMv7 version of the architecture; thus, they are higher performance per clock cycle than the ARM11, which uses ARMv6.

Answer 2

This is already the correct answer IMO, and what I am suggesting will not probably not make much difference, but it might be useful to know.

If all you want to do is run the browser, you don't have to run a desktop environment as well. Create a file which looks like this as $HOME/.xinitrc:

#!/bin/sh

midori

If .xinitrc already exists, move it temporarily or comment out anything else. Now, startx (obviously, you should not be in it already -- do this from the console without the GUI running). Voila, you have just the browser, no desktop.

That saves a wee bit of memory, although the browser is by far the elephant in the room and the Xorg server itself (that's running) is bigger than a basic lxde (which now isn't running). If you have so much loaded into RAM that you are using swap, that will impact performance. The above midori + bare X uses < 100 MB resident according to 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

That's with 4 tabs open. Again, if you look at these and see your RAM is near full, that's a performance issue. Note that it is normal to use a bit of swap even if the ram is not full, so don't worry about that -- that swapped stuff is low priority.

Something further to think about, performance wise, is the significance of buffers and cache. I did not include these in the total, and notice it is actually more than the committed memory (about twice as much). That is normal. If you fill the memory up with committed stuff, the system will just use less cache and/or transfer it to swap. Either way, that is going to be a performance degradation because the cache is important (it's just not vital or immutable size wise, so not part of the committed mem stat).

In other words, optimally you want your committed ram to be no more than 75% of what's available on the pi and perhaps less than that. If you use LXDE and start opening other stuff, you may quickly start to approach that.

Answer 3

Disclaimer: The following describes using of experimental features with dubious effects. Make sure to test for introduced regressions and actual performance gains.

You could try some of Google Chrome's / Chromium's flags under under chrome://flags to improve the (apparent) browsing performance. There is an article explaining some of the flags relevant to performance. I will try to collect some here:

Forcing GPU acceleration in by enabling "Overrrite Software Rendering List" will use the GPU for rendering at the cost of possible artifacts, even if the driver is not whitelisted. I do not know how well this works with the Pi's GPU, though.

GPU compositing on all pages will use the GPU to scroll all layers. So scrolling performance should improve on pages without GPU-accelerated layers.

Refresh window tilewise would be another hint. It will render tiles and display each as soon as it is ready instead of waiting for the last one to finish. In effect rendering will take longer due to the introduced overhead, but content will appear faster.

Rendering in separate thread will do the rendering asynchronously and keep the interface responsive. You can scroll while the page is still rendering.

Disable GPU VSync will update the rendered contents regardless of whether the monitor has loaded them yet. This improves the frame rate at the cost of inconsistent presentation.

After enabling/disabling any switches, you will have to restart Chrome/Chromium for the setting to apply. The button at the bottom of the flags-page can do that for you.

Going even further, command line switches could be used to optimize Chrome/Chromium. See the List of Chromium Command Line Switches for a complete list.

--default-tile-width and --default-tile-height could be set to match a fraction of the screen size to speed up initial rendering of each page.