LinuxSpeedup

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 [http://wiki.kde.org/tiki-index.php?page=Performance%20Tips the KDE Performance Tips].
To reduce memory usage:
- 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.

Renice esd/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 (my woody box did). Deprecated with kernel 2.6 and ["XFree86"] 4.3.
gpm (see ["GPMMouseConfig"]) 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.
[http://and.sourceforge.net/ 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 hereup if you configure it right.

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.

Use mozilla 1.1 or + (much faster redraw than 1.0): I don't know if 1.1 enables it already 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 [http://www.kde.org KDE 3.2]. The rewritten kwin is faster than the previous one. It has also many new features. A very good upgrade in my opinion. Consider ["DebianKDE"].
Use an up-to-date version of GTK+ 2.x. (wow, the version Redhat is packaging is much faster at rendering AA text than the old snapshot I had from Ximian)
Use gnuserv mode in emacs/emacs
Use [["XFree86"] http://www.xfree86.org] 4.2 or more, it loads fonts a lot faster (because it uses a cache).
Develop directly from Sid to get new packages that can make the system feel nicer. Consider ?CopingWithUnstable though

Use a 2.6 kernel whenever possible. It includes a lot of improvements for speed and better use of your hardware.

Use a kernel shipped with Debian and optimized for your CPU's architecture. You could already notice HUGE improvements.

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

Compile for your specific processor architecture! this makes sure that you are actually using the new features your processor provides...
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 [http://members.optusnet.com.au/ckolivas/kernel/ Kernel patch homepage of Con Kolivas] for a fairly complete list.

Use devfs (see ["DevFAQ"]), or preferably udev if on a 2.6 kernel, as devfs has been deprecated. Should be faster when seeking for a peripheral as well as provide with more flexibility when using hotpluggable hardware (ex: USB) and present a clearer /dev for the newcomer.

Prelink your binaries, especially OpenOffice. See: [http://people.debian.org/~chris/prelink/ 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 [http://www.gentoo.org/doc/en/prelink-howto.xml Gentoo prelink howto] (somewhat useful for Debian, too). There is no prelink package in Woody because prelinking requires a newer libc version than Woody's. It exists in Sarge/Sid though and 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.