WARNING

Much of this content appears dated, as of April 2007. Be careful!

Disabling

• To reduce CPU usage:

  • If you are running KDE (see DebianKDE), do not use the newsticker - at least not with many sources. This can consume over 90% of your CPU resources. If you have a poor performance and you see "kdeinit: kicker" on the first ranks in top then it's probably the newsticker. In particular, consult the KDE Performance Tips

• To reduce memory usage:

  • If you're looking to manage programs starting up at boot time, download one of sysv-rc-conf, sysvconfig, and rcconf. All are graphical programs to be run as root making changing boot priorities easy.

  • Uninstall or at least stop any unneeded service (Apache, PostgreSQL, XFS (the X Font Server), Samba, ?MySQL, ...) with update-rc.d -f apache remove for example (not quite the right way to do it, because on next upgrade of the service, it will put the links back)

  • Use mingetty, or better, fgetty, instead of getty. Even better, reduce the number of *gettys used if you know you'll never switch to console

Niceing (from highest to lowest priority)

• AND (the Auto Nice Daemon) should be used to renice or kill programs that get too much or too few priority, as well as those often going bersek (like gnome-spell used to). It should completely remove the manual mess recommended below if you configure it right.

• Renice alsa/artsd to -15. If these don't get CPU right away when they need it, your sound will break up.

• Jack the nice value of X from 0 to -10. The nice value doesn't make it much "faster", but it does significantly improve latency. There is a debconf question for that, if you need to do it at all. Check first if it's not running nice -10 out of the box. Deprecated with kernel 2.6 and XFree86 4.3

• This is obsolete. Xorg and gpm both talk to /dev/input/* device nowadays.gpm (see GPM section in XFreeConfig) should be niced to match X when acting as a repeater. (Should it be even higher priority? & Why use gpm?)

• Software that's always sucking down a little CPU in the background but still should be interactive (like lopster or gtk-gnutella) should be niced to 5 or so.
• If you run any servers on your workstation, they should run around nice 10. They need to get back to the user, but they shouldn't make your UI get unpleasant when they get hit.

• Make all your cron jobs run at nice 20 (crontab -e, edit command line to contain nice -n20). They have no reason to demand interactive latency, and you do need said latency for your UI.

Low-level Tuning

• Turn on DMA and unmasked interrupts (insert usual warnings about potential problems with really old computers having these on). Significantly reduces "jerkiness" in X when doing disk access, including paging. See the two following points. Try the options first, then run hdparm at boot time. The easiest way is to install hwtools and edit /etc/init.d/hwtools

  • You can do "hdparm -c3 -d1 /dev/yourharddrivenamehere" with almost no risk.
  • With caution (backup your data first) you can play with the -u and -m options (preferentially with your device mounted ro).
  • Sarge's hdparm seems to get all this almost optimal.

Updating

• ?IceWeasel - I don't know if its enabled by default but you can tweak the redraw speed by adding the line user_pref("nglayout.initialpaint.delay", 100); into user.js. If you don't find any such file in your system, just create one with the said line in it in the directory under ~/.mozilla where your prefs.js resides.

• Use gnuserv mode in emacs/xemacs.

• Develop directly from Sid to get new packages that can make the system feel nicer. Consider ?CopingWithUnstable though

Kernel

(see ?KernelALaDebian)

Use a kernel optimized for your CPU's architecture (see ?InstallingOptimizedKernelPackage).

?BuildYourOwnKernel images with the following points bearing in mind. This can make a BIG difference in speed! (Tempered by difficulty to implement):

• Enable only the stuff that you really need.

• Include things like the low-latency patch and the preemption patch which make the system feel faster. At least the preemption patch is included in the 2.6.x series and only requires turning on before compiling. The low-latency patch is a special case where a prebuild kernel can be used for both desktop and server, by switching low-latency with echo 1 > /proc/sys/kernel/low-latency.

Refer to the Kernel patch homepage of Con Kolivas for a fairly complete list.

Reduce the installation footprint

ReduceDebian Smaller footprint packages use less resources, and generally run quicker.

Other

• Prelink your binaries, especially OpenOffice. See: Debian page about prelinking (this page seems to be dead; there is an archived version of this page at http://web.archive.org/web/20031010172145/http://people.debian.org/~chris/prelink/ ) and Gentoo prelink howto (somewhat useful for Debian, too). OpenOffice's installation will ask you if you want to prelink it if package prelink has been installed before.

• Install package libc6-i686, which improves things on any decent, modern CPU.

Further Reading

• Improve Linux performance: http://www-106.ibm.com/developerworks/linux/library/l-perf/?ca=dgr-lnxw83FasterLinux

• Tweaking Tux:

  • 1: http://www.linuxjournal.com/article.php?sid=5310

  • 2: http://www.linuxjournal.com/article.php?sid=5309

  • 3: http://www.linuxjournal.com/article.php?sid=5308

  • 4: http://www.linuxjournal.com/article.php?sid=5307

  • 5: http://www.linuxjournal.com/article.php?sid=5306

• How to boot GNU/Linux faster (a.k.a. using make to manage services dependencies):

  • http://www-106.ibm.com/developerworks/linux/library/l-boot.html?ca=dgr-lnxw09BootFaster

  • http://linuxdevices.com/articles/["AT7172642614"].html (LinuxDevices' mirror of the above.)

Based on suggestions made on Slashdot on the Redhat 8.0 Reviewed topic.

Contributors: JeromeWarnier, MarkBucciarelli, DavidAndel, Leonithas Arvanitis, CarlosVieira