sam_p_lay
Posts: 52
Joined: Fri Jan 11, 2013 12:15 am

Improving browsing performance

Fri Jan 18, 2013 8:53 am

Hi people,

I've got my R-Pi up and running with Bodhi (after trying RiscOS and Raspbian) and I'm really disappointed in the web browsing performance. I know ARM11 isn't the most powerful CPU in the world, but there must be some way to get more performance out of it? I've got my Pi overclocked to 950MHz and I'm using Midori (with nothing else open) but it's still really slow.

So I'm wondering if anyone has any tips for improving performance? I'd be happy to ditch the GUI altogether if I can still run a graphical mouse-driven browser from the command line. Is that possible with Linux or would that be the equivalent of trying to run a Windows program in DOS? Not really interested in text-based browsers. Is there a version of Raspbian that comes without a window manager? And if not, which is more lightweight - LXDE or Enlightenment 17? Thanks for reading.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25906
Joined: Sat Jul 30, 2011 7:41 pm

Re: Improving performance

Fri Jan 18, 2013 9:05 am

sam_p_lay wrote:Hi people,

I've got my R-Pi up and running with Bodhi (after trying RiscOS and Raspbian) and I'm really disappointed in the web browsing performance. I know ARM11 isn't the most powerful CPU in the world, but there must be some way to get more performance out of it? I've got my Pi overclocked to 950MHz and I'm using Midori (with nothing else open) but it's still really slow.

So I'm wondering if anyone has any tips for improving performance? I'd be happy to ditch the GUI altogether if I can still run a graphical mouse-driven browser from the command line. Is that possible with Linux or would that be the equivalent of trying to run a Windows program in DOS? Not really interested in text-based browsers. Is there a version of Raspbian that comes without a window manager? And if not, which is more lightweight - LXDE or Enlightenment 17? Thanks for reading.
There should be some improvements coming with the X acceleration (see the appropriate thread), but it appears that a lot of applications are simply really badly coded and are quite inefficient with regard to their graphics output. This isn't evident with the fast desktops we have nowadays, the problem was there but masked by throwing horsepower at it. So, the apps themselves do need to be improved to get really decent performance.

Other people may be able to suggest alternatives that are not so inefficient.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“My wife said to me `...you’re not even listening`.
I thought, that’s an odd way to start a conversation.."

User avatar
hicksonj
Posts: 13
Joined: Wed Aug 01, 2012 11:51 am
Contact: Website

Re: Improving performance

Fri Jan 18, 2013 9:10 am

Why not go for 1GHz Turbo mode? This gives me expectable performance with Midori, etc, but still obviously not as "snappy" as a PC. Midori needs X, so (AFAIA) you need to be running X. Someone will now prove be wrong.

If this doesn't work, your expectations are too high. The Pi is an amazing device for £30. That is part of the fun.

BTW Quake and PenguinsPuzzle (e.g. OpenES stuff) crash for me at 1GHz Turbo mode, so I just turn it down to 900Hz for that. This is no problem for me. For 95% of the time, Turbo mode rules. 8-)

Cloudcentric
Posts: 982
Joined: Fri Sep 14, 2012 9:13 am

Re: Improving performance

Fri Jan 18, 2013 9:19 am

I have been using Arch Linux Arm aka alarmpi without a desktop environment and running Midori Web Browser in Kiosk Mode

http://www.raspberrypi.org/phpBB3/viewt ... 1&p=261874

http://archlinuxpi.blogspot.co.uk

That being said in the Pi defence, it was never envisaged to be a main computer, it was developed as a learning tool:

http://www.zdnet.com/we-thought-wed-sel ... 000009718/
I know everything about nothing"

MAA1612
Posts: 18
Joined: Thu Jan 17, 2013 11:00 am

Re: Improving performance

Fri Jan 18, 2013 9:40 am

sam_p_lay wrote:I've got my R-Pi up and running with Bodhi (after trying RiscOS and Raspbian) and I'm really disappointed in the web browsing performance. I know ARM11 isn't the most powerful CPU in the world, but there must be some way to get more performance out of it? I've got my Pi overclocked to 950MHz and I'm using Midori (with nothing else open) but it's still really slow.
You might underestimate the complexity of modern web pages. A couple of years ago, 512 MB RAM and moderate processing power have been sufficient for a satisfying browsing experience, but today, even an average news portal requires far more RAM and processing power than simple office applications in order to be rendered fluently. Of all the standard applications (word processing, e-mails, media playback, etc.), web browsing has become one of the most demanding.
So I'm wondering if anyone has any tips for improving performance?
One thing that might help would be blocking all the advertisments. However, the usual addblocker plugins for browsers are quite demanding themselves. Thus, they do not really help. One thing that could work would be a local firewall that blocks all the common ad networks.
I'd be happy to ditch the GUI altogether if I can still run a graphical mouse-driven browser from the command line. Is that possible with Linux or would that be the equivalent of trying to run a Windows program in DOS? Not really interested in text-based browsers.
Browsers that run on the command line, are always text-based. Theoretically, graphical browsers that avoid the X protocol, are possible, but I doubt that there would be great performance benefits.
Is there a version of Raspbian that comes without a window manager?
You could just deinstall all window managers, but stil, all common graphical web browsers are compiled against X.
And if not, which is more lightweight - LXDE or Enlightenment 17? Thanks for reading.
Does not matter. Both are so lightweight that they will not have a significant impact on browsing speed.

Best regards,
Alexander

sam_p_lay
Posts: 52
Joined: Fri Jan 11, 2013 12:15 am

Re: Improving performance

Fri Jan 18, 2013 9:54 am

Thanks for the replies people!

Jamesh - are you talking about GPU acceleration? It does seem a shame to waste all that horsepower and to not take advantage of the strengths of the hardware. I did suspect that with time, performance will get better.

Hicksonj - thanks for the suggestion, but is 50Mhz really going to make that much difference? Only a 5% gain on 950MHz and raspi-config told me that clock speed can result in data corruption.

Cloudcentric - thanks - I'm gonna try that! As for being a learning tool, that actually will be one of my main uses. I'd like to learn Android app development, and figured getting a solid foundation in programming basics with Python would be a good starting point. But keep in mind these tutorials are online and I'm expecting I'll want several learning resources open in different tabs.

MAA1612 - I had the exact same thoughts about banner ads slowdown vs adblock slowdown. Came to the same conclusion - I'd probably lose as much performance blocking the ads as just rendering them. At least they're not gonna be Flash! I know sites have become more complex (I actually make a living as a PHP dev) but ALL sites are laggy - even this forum which looks pretty basic to me.

With regards to X, I've never fully understood the distinction between X and GNOME/KDE/etc. I realise a DE/WM is built on top of X and a toolkit like GTK+ or Qt but I was under the impression X can be run without any GUI? Kind of like giving DOS the ability to fire up IE but I suppose without the window title/border?

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25906
Joined: Sat Jul 30, 2011 7:41 pm

Re: Improving performance

Fri Jan 18, 2013 10:09 am

sam_p_lay wrote:Thanks for the replies people!

Jamesh - are you talking about GPU acceleration? It does seem a shame to waste all that horsepower and to not take advantage of the strengths of the hardware. I did suspect that with time, performance will get better.
Yes, using the GPU can speed up some stuff - BUT, investigations by teh_orph have shown that some browsers are really really bad at rendering pages - for example, they send many thousands of drawing operations FOR ONE PIXEL AT A TIME. This cannot be GPU accelerated - the overheads for packaging up the command, sending it to the GPU and waiting the result are much higher than any savings made. In fact, the benefit of the GPU only becomes apparent once you start working on quite large pixel clumps. teh_orph's stuff (see his threads) take this in to account, and there are some improvements.

IMO, this is bad coding on behalf of the writers of the HTML renderer. They have become so used to high powered machines, they no longer pay any attention to making code efficient. It why Windows 7/8 needs a multi core 3Ghz machine to do the same work we used to do on 166Mhz Pentiums with vastly less memory. I recently heard about engineers who shall remain nameless, when confronted with a speed issue on the Raspi, who just said "Oh, there'll be a faster Raspi along soon *, there's no point in making the code efficient" That is a terrible attitude. Don't get me wrong, spending too much time on optimisation can be counterproductive. but you should never ignore it completely in the hope faster machines come along.

* Not in the next year or two there won't.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“My wife said to me `...you’re not even listening`.
I thought, that’s an odd way to start a conversation.."

MAA1612
Posts: 18
Joined: Thu Jan 17, 2013 11:00 am

Re: Improving performance

Fri Jan 18, 2013 10:14 am

sam_p_lay wrote:With regards to X, I've never fully understood the distinction between X and GNOME/KDE/etc. I realise a DE/WM is built on top of X and a toolkit like GTK+ or Qt but I was under the impression X can be run without any GUI? Kind of like giving DOS the ability to fire up IE but I suppose without the window title/border?
Yes, it is possible to run X without window manager, but then your applications will not have borders, close buttons, etc.

Just create a file ~/.xinitrc, and put in the name of the application to be called when you run startx. Usually, this would be the name of a terminal emulation that can be used to start other programs. Alternatively, you could also put in the name of your web browser directly, but then it would not be possible to run any other programs from within X.

sam_p_lay
Posts: 52
Joined: Fri Jan 11, 2013 12:15 am

Re: Improving performance

Fri Jan 18, 2013 10:21 am

That really is a bad attitude (too bad you won't name names :-D). I wonder what it would take to make this responsive? Dual Cortex A9 @ 1.5GHz? Quad A15? Looking at Android and the way each new phone I get has more and more processing power but also a newer OS and never seems to get to being perfectly smooth/responsive, I'm wondering if any ARM-based CPU can match x86 for responsiveness.

With this kiosk script, I've just created a text file in /home with no file extension. Is that correct? I can't run it without the GUI because raspi-config won't allow me to not boot to desktop. I've done it twice now and said yes to reboot and both times I've ended up back in Enlightenment. Tried it from the terminal but got some errors about display server already being started (guess it's not designed to be run while I'm already in the GUI?).

sam_p_lay
Posts: 52
Joined: Fri Jan 11, 2013 12:15 am

Re: Improving performance

Fri Jan 18, 2013 10:24 am

MAA1612, where would I create that file? In /home? I've seen the ~/. before - what does it mean?

MAA1612
Posts: 18
Joined: Thu Jan 17, 2013 11:00 am

Re: Improving performance

Fri Jan 18, 2013 10:30 am

sam_p_lay wrote:MAA1612, where would I create that file? In /home? I've seen the ~/. before - what does it mean?
Yes in your home directory. "~" is just an alias for /home/<username>.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25906
Joined: Sat Jul 30, 2011 7:41 pm

Re: Improving performance

Fri Jan 18, 2013 10:35 am

sam_p_lay wrote:That really is a bad attitude (too bad you won't name names :-D). I wonder what it would take to make this responsive? Dual Cortex A9 @ 1.5GHz? Quad A15? Looking at Android and the way each new phone I get has more and more processing power but also a newer OS and never seems to get to being perfectly smooth/responsive, I'm wondering if any ARM-based CPU can match x86 for responsiveness.
.
It's not a processor issues (Arm, X86, Mips whatever), it's efficiency in coding issue. A single core 1Ghz Arm should be more than adequate to run a web browser. Efficient code is efficient code on whatever platform.

Arm is slower than X86 at similar clock rates, but not by a huge amount.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“My wife said to me `...you’re not even listening`.
I thought, that’s an odd way to start a conversation.."

sam_p_lay
Posts: 52
Joined: Fri Jan 11, 2013 12:15 am

Re: Improving performance

Fri Jan 18, 2013 10:41 am

Judging by that then, Android is pretty badly-written too?

MAA1612 - thanks, I'm gonna try that now! Just create .xinitrc with a single line:

terminology

?

MAA1612
Posts: 18
Joined: Thu Jan 17, 2013 11:00 am

Re: Improving performance

Fri Jan 18, 2013 10:47 am

sam_p_lay wrote:MAA1612 - thanks, I'm gonna try that now! Just create .xinitrc with a single line:

terminology
If you have installed a program named "terminology", this would be correct.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25906
Joined: Sat Jul 30, 2011 7:41 pm

Re: Improving performance

Fri Jan 18, 2013 10:58 am

sam_p_lay wrote:Judging by that then, Android is pretty badly-written too?
Android is quite 'heavy'. Some of it is written in a Java like language which is interpreted, which is slower than, for example, C/C++ code. There's also a lot of C++, which is fairly fast as a language, but again, susceptible to inefficient code. The underlying OS code in Android is Linux, which IS efficiently written. Worth noting that Google don't use X in Android, they wrote their own graphics stack, because X was too slow.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“My wife said to me `...you’re not even listening`.
I thought, that’s an odd way to start a conversation.."

sam_p_lay
Posts: 52
Joined: Fri Jan 11, 2013 12:15 am

Re: Improving performance

Fri Jan 18, 2013 11:09 am

Well the default terminal in Enlightenment 17 (Bodhi's WM) is called Terminology. Nothing happened when I rebooted though. And wouldn't this still boot into Enlightenment and just fire up a terminal? What's the difference by the way between .bashrc and .xinitrc? They both seem to be like DOS's autoexec.bat but run when your GUI loads?

I didn't realise C/C++ are faster than Java. I was equally up for learning either but Apple's C ('Objective-C') is some kind of Apple implementation of C? I figured Java will be a more transferable skill to have. Plus I don't really want to get involved with Apple or make them any money :-D

And I had heard about X being a bit of a dinosaur now - read it's being replaced by a display server called Wayland? I didn't know what the shortcomings of X were, but performance is always a good reason :-)

User avatar
rurwin
Forum Moderator
Forum Moderator
Posts: 4258
Joined: Mon Jan 09, 2012 3:16 pm
Contact: Website

Re: Improving performance

Fri Jan 18, 2013 11:12 am

sam_p_lay wrote:That really is a bad attitude (too bad you won't name names :-D). I wonder what it would take to make this responsive? Dual Cortex A9 @ 1.5GHz? Quad A15? Looking at Android and the way each new phone I get has more and more processing power but also a newer OS and never seems to get to being perfectly smooth/responsive, I'm wondering if any ARM-based CPU can match x86 for responsiveness.
Fred: This RaspPi/Android/Mac is not very responsive. Look at the lag here
Joe: Your Windows PC does the same
Fred: That's because it's only a dual core with 4GB memory. I wish I could afford a new Nvidia card; this one's over a year old.
jamesh wrote:they wrote their own graphics stack, because X was too slow.
X is notoriously slow. It is based on a particularly inefficient protocol. We used to notice significant lag on a 10Mbit Ethernet. OTOH, it was and is faster than any competitor.

That Wayland looks very interesting... and it is GL/ES2.
Last edited by rurwin on Fri Jan 18, 2013 11:31 am, edited 1 time in total.

sam_p_lay
Posts: 52
Joined: Fri Jan 11, 2013 12:15 am

Re: Improving performance

Fri Jan 18, 2013 11:21 am

Point being we throw more money at PCs so better performance is to be expected? I've used a wide range of PC hardware and not once have I ever had to wait for typing to catch up with me. Only time I recall that ever being the case was on the BBC/Acorn computers we had at school. How we laughed at their performance :-) Weren't they where the RISC-based CPUs began?

By the way, why nVidia graphics specifically? It's been my experience that it's AMD who abandon previous-gen GPUs as soon as the line launches.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25906
Joined: Sat Jul 30, 2011 7:41 pm

Re: Improving performance

Fri Jan 18, 2013 11:31 am

sam_p_lay wrote:Point being we throw more money at PCs so better performance is to be expected? I've used a wide range of PC hardware and not once have I ever had to wait for typing to catch up with me. Only time I recall that ever being the case was on the BBC/Acorn computers we had at school. How we laughed at their performance :-) Weren't they where the RISC-based CPUs began?

By the way, why nVidia graphics specifically? It's been my experience that it's AMD who abandon previous-gen GPUs as soon as the line launches.
Let me say it again - this is not a problem with processor architecture as you seem to imply. It's a problem with bad code.

Remember that the Arm cpu performance of a Raspi at standard clock is roughly equivalent to a 300Mhz Pentium of about 10 years ago.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“My wife said to me `...you’re not even listening`.
I thought, that’s an odd way to start a conversation.."

User avatar
rurwin
Forum Moderator
Forum Moderator
Posts: 4258
Joined: Mon Jan 09, 2012 3:16 pm
Contact: Website

Re: Improving performance

Fri Jan 18, 2013 11:38 am

sam_p_lay wrote:Point being we throw more money at PCs so better performance is to be expected?
The point being that the problem exists on all hardware, but when it's on a PC you blame something else.

Software bloat is the problem; both feature-wise and RAM-wise.

I once wrote and sold a commercial application on a 6502-based device with no RAM in it at all.

sam_p_lay
Posts: 52
Joined: Fri Jan 11, 2013 12:15 am

Re: Improving performance

Fri Jan 18, 2013 11:56 am

But just a Windows PC right? :-) Honestly, I've never had a complaint about Windows (or desktop Linux) performance with the exception of my girlfriend's Atom N450-based netbook, which she refuses to allow me to install Linux on.

I'll absolutely accept that bad code is a major cause of the problem, but how does it help? What can we do about that? And I guess it's just coincidence that it's only ARM-based systems I've had to wait for typing to catch up to me. I don't fully understand how ARM, Acorn, Farnell/Element14 and the foundation are related to each other (they have a common origin right?) but wasn't it the same guys that wrote RiscOS on those Acorns that also developed the instruction set and processor? Surely they could code that better than anyone?

User avatar
rurwin
Forum Moderator
Forum Moderator
Posts: 4258
Joined: Mon Jan 09, 2012 3:16 pm
Contact: Website

Re: Improving performance

Fri Jan 18, 2013 12:44 pm

sam_p_lay wrote:But just a Windows PC right? :-) Honestly, I've never had a complaint about Windows (or desktop Linux) performance with the exception of my girlfriend's Atom N450-based netbook, which she refuses to allow me to install Linux on.
I've had Windows PCs when I had to wait for typing to catch up. Often. OTOH I've never noticed unacceptable lag on any device unless it was malfunctioning or too highly loaded.
I'll absolutely accept that bad code is a major cause of the problem, but how does it help? What can we do about that?
Write better code, and choose applications and infrastructure that are efficient. Do not expect a small cheap device like the RaspPi to do stuff it cannot do efficiently.
I don't fully understand how ARM, Acorn, Farnell/Element14 and the foundation are related to each other (they have a common origin right?)
Only very vaguely. Acorn begat ARM, then spun it off as an independent company. Element14 is not related to Acorn, although Acorn spun off a company with that name which is now part of Broadcom. It is a popular name; see a periodic table to understand why. There is no relationship to the foundation except that some of them work for Broadcom, which owns that other Element14 and is an ARM licensee.
wasn't it the same guys that wrote RiscOS on those Acorns that also developed the instruction set and processor? Surely they could code that better than anyone?
RiscOS has, like Windows, been taking advantage of increasing processor power over then last thirty years. It did not stand still once it was written by the Acorn/ARM people. The RiscOS that ran on the Archimedes would not run on the RaspPi since the screen architecture is completely different and there was no USB in those days. Support for such changes has been added later. While I would trust RiscOs programmers rather more than I would trust Windows programmers to write efficient code, they're still human, and they still want to implement the next ultra-cool feature. They still want to own the newest and fastest computers, and they still write their software to work on those.

sam_p_lay
Posts: 52
Joined: Fri Jan 11, 2013 12:15 am

Re: Improving performance

Fri Jan 18, 2013 1:02 pm

Well you seem to know your stuff, appreciate your breakdown of the relationships between these companies. Do you have any suggestion for my situation? The Matchbox+Midori kiosk approach sans-WM looks promising to me, but raspi-config isn't working for the option to not boot to the GUI. Should I re-image again? And will I be able to multitask and alt+tab at the command line to switch between the browser and my code? I'd be doing the programming exercises as I read them.

Cloudcentric
Posts: 982
Joined: Fri Sep 14, 2012 9:13 am

Re: Improving performance

Fri Jan 18, 2013 1:11 pm

Personally would use another SD Card and experiment with Arch Linux.

RiscOS, piCore, and Slitaz unfortunately do not have an up-to-date web browser as yet....


Regards bloat, though **-DOS was single-tasking, I managed to run on on some very low powered machines, even had a Desktop and in DR-DOS Task Switching so could launch another program while leaving the other program paused in the background.

Admittedly a 486DX66 with a 512MB Hard Drive and 8MB Memory was useful.......

http://glennmcc.dyndns.org/download/masrtin
I know everything about nothing"

User avatar
rurwin
Forum Moderator
Forum Moderator
Posts: 4258
Joined: Mon Jan 09, 2012 3:16 pm
Contact: Website

Re: Improving performance

Fri Jan 18, 2013 1:27 pm

I think you have a strange understanding of how X works. If you don't run X then you don't get windows and you can't alt-tab to anything. There are browsers that work in text mode, try Lynx, but your tutorial site is more than likely to not work well with it.

So to read your tutorial, you probably need to run X. You can cut down the amount of work the computer is doing by not running a desktop manager in X, and just run a window manager. twm is probably a good small one. But that is not likely to affect Miduri much and setting it up requires you know quite a bit more than just how to stop running X on boot.

The other thing you can do is to use Ctrl-Alt-F# to switch to a command line and use that for your editor and compiler. Like running twm it only works faster because it takes less memory and CPU cycles from Miduri. It's a whole-screen thing though; it will be a pain to have to keep switching back and forth. You will find editing in a text screen to be a "challenging learning experience."

Otherwise use a simple editor like leafpad to edit your code, and compile it in a terminal window. Do not use an IDE; they are too memory and CPU hungry. Don't even think about considering to use Eclipse.

Return to “Troubleshooting”