Take the 2-minute tour ×
Raspberry Pi Stack Exchange is a question and answer site for users and developers of hardware and software for Raspberry Pi. It's 100% free, no registration required.

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?

share|improve this question
    
And the pi is driving a 3.5" 480 x 800 screen? ;) If not perhaps that alone is a bit of a factor... –  goldilocks Feb 24 '13 at 23:42
    
A VGA monitor is used for display, through a HDMI-to-VGA cable, and config is hdmi_mode=35 1280x1024 60Hz ... But I can't see any improve after changed the config to hdmi_mode=9 800x600 60Hz –  hello.wjx Feb 25 '13 at 5:56
    
No doubt. I think tapped-out has the correct answer to this question but I added another one with an idea for you. –  goldilocks Feb 25 '13 at 14:25

3 Answers 3

up vote 13 down vote accepted

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.

share|improve this answer

Tapped-out already answered this, and what I am suggesting will not make much difference in this case, 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.

share|improve this answer

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.

share|improve this answer
    
I tried flags Override software rendering list, GPU compositing on all pages and Threaded compositing on Pi, but there seems no apparent improvements. I alse tried those flags on PC, seems no improvements, too. –  hello.wjx Feb 27 '13 at 4:44
    
Make sure to restart Chrome after editing flags. To test Override software rendering list open a WebGL demo. To test Threaded compositing try scrolling while a big page is still loading. –  Bengt Mar 1 '13 at 15:37
    
From what I'm reading here: chromium.org/developers/design-documents/… using "Threaded compositing" won't help on the pi -- it only has one core -- and may make it worse, depending on how significant "operat[ing] on a copy of the current rendering state" is. –  goldilocks Mar 5 '13 at 13:29
    
The page load performance will decrease, yes. But Javascript will not block and wait for rendering and the page will stay responsive. You are trading some objective performance for some perceived performance. –  Bengt Mar 5 '13 at 18:12

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.