- X Speed Issues
- What About System Speed?
- Replace Drivers or X
- Choosing The Right Environment
- The Right Programs
X Speed Issues
X wasn't designed to be a speedy single user graphical environment. Development focused on portability and
X isn't an inherent part of any operating system, and direct access to the system core is only granted reluctantly.
For the most part drivers have not been written by the hardware vendors but by interested programmers, either sponsored by a Linux company or even in their free time.
X by itself isn't really useful: you'll need another program to draw the windows, the menus, the background etc. This window manager adds another layer between the user and the operating system. Desktop environments like KDE or GNOME even add yet another layer to provide more and more uniform functionality.
All this explains why the graphical subsystem on Linux doesn't share the 'snappiness' of its Windows counterpart. On the same hardware, MS Windows usually is faster than X on Linux, although given the proper drivers, the race can get.
What About System Speed?
Slow response times in X can be the symptom of an issue with the system's configuration, be it hardware or software. If you are running your Linux system off an IDE hard drive, read the section onin the article on IDE hard drives.
As for hard drives themselves, I'd suggest using 7600 RPM / UDMA 66 drives for the best price / performance ratio. As for graphics cards, there isn't much of a difference in 2D speed between most models up to two years old. In 3D speed, the nVidias are currently unrivaled on Linux.
Another thing to check is the list a currently running.
Replace Drivers or X
Some graphic cards vendors offer proprietary Linux drivers for their hardware. These drivers usually offer enhanced functionality and better acceleration. Likewise there are vendors who offer alternative X server implementations for Linux which might provide a speed boost, too.
On the other hand, you have to address the vendor or other users when you've got problems with them, since Mandrakesoft does not support proprietary third party software. Furthermore do some third party graphics drivers do not support X servers other than XFree86, so caveat emptor.
See for details.
Free alternative windowing systems likeand are in the works, but since they would require massive changes to vast amounts of current software, developers have so far been very hesitant in adopting them.
The Right Window Manager / Desktop
You can regain some speed by partially reversing the deal: trade functionality for speed and use a 'thin' window manager instead of sophisticated environments likeor . Window managers like Blackbox, ~IceWM or Window Maker are provided on your Mandrake Linux CD, and they use only a fraction of the resources environments need. You'll find more information on them on the page.
But maybe you don't even have to go that far if you:
- … only use as many virtual desktops as you really need. By default and come with four virtual desktops running, which is a bit of an overkill for most users. Turn them off, then.
- … avoid full-scale wallpapers. If you can't live without a colorful background use small pictures and tile them.
This is often underestimated: four virtual desktops with different full-scale wallpapers at a color setting of 24 bpp and a resolution of 1024x768 eat some 8 MB of system memory1.1
- … turn off screensavers. They are loaded into system memory on startup even if you do not use them. A simple screen blanking might not look very fancy but it is more efficient. If you enable power management as described on , a screensaver is superfluous anyway.
- … use lower color depths. 16 bpp instead of 24 bpp don't make any real difference in appearance but in terms of memory usage they do. Run 'XFdrake' or the 'Xconfigurator' again to change this. You'll find a discussion of this topic in .
- … prefer light-weight themes. If you are fond of eye-candy, you don't really want to do without a nice desktop theme. But since there are , you might find one that's nice and light.
- … not load gazillions of fonts. This puts a heavy load on both, xfs and X. You can load fonts on demand. Just put them into a directory which is not part of the default font path and load that directory as 'root' with
service xfs restart
when needed. Likewise use chkfontpath ––remove directory and the 'service' command to unload the directory again.
- … turn off font anti-aliasing (AA). AA is a huge resources sink (looks pretty, though ;-)). If you can't do without AA, at least edit '/etc/X11/~XftConfig' as 'root' and remove all directories from that file which are not present on your system. This will improve startup time of programs.
- … start X from the console with startx or via 'autologin' and thus avoid loading a display manager. See the article on .
The Right Programs
If you use desktops likeor , you should prefer using the programs supplied with them, because these programs won't have to load their own libraries into system memory. Notice that programs need to load a good deal of 's code when you run them in an environment other than .
Try to avoid statically linked programs. These programs usually use graphics sets not common in the Linux world (like Motif). They can take very long to load, eat up much memory and are usually less stable than programs which rely on system libraries.
Consider that console programs often can't be beaten in terms of low memory usage, stability and flexibility. They often lack intuitiveness, though. Often enough there are also lighter graphical alternatives available.
- Mozilla web browser: 17 MB on startup. Konqueror web browser in KDE: 6 MB on startup. w3m console browser: 1.5 MB on startup.
- Konqueror file manager in KDE: 6MB on startup. mc: 1.2 MB. And you can't even browse RPMs with 'kfm' like you can with 'mc'.
- KMail mail program: 6.5 MB on startup. Mutt in terminal: 2.2 MB. And Mutt offers more functionality than kmail (although it can be a pain to configure).
- konsole terminal emulator: 4 MB on startup. rxvt terminal emulator: 1 MB.
Do not use 'top' and its graphical frontends, because their numbers are often misleading or even inaccurate.
Revision / Modified: June 20, 2002
Author: Tom Berger
Legal: This page is covered by the. Standard disclaimers of warranty apply. Copyright LSTB and Mandrakesoft.
Version 1.4 last modified by Flink on 21/01/2005 at 19:51