I can't take credit for it - I saw it linked in another thread here some time ago. Now every time I see talk of optimizing for speed I think of it. It is hilarious, and often so close to the mark!

You could also rebuild every Slackware package with the -O3 optimization level rather than -O2 default, but you risk serious instability issues if you do.

That is not a good idea, and the costs would outweigh the benefits, especially stability-wise. Using '-march=native' is safe, while '-O3' is not guaranteed to be. With so many packages to rebuild the time used would not be worth the minor performance increase.

Exactly. Often you'll find that running correctly and stably doesn't involve calculating speed into the equation.

:) so do you stick with the default kernel or do you upgrade with new releases?

If there is no need I don't upgrade it

I tend to kernel-hop until the system stops having issues. Although, to be fair, sometimes I just upgrade because the new features sound awesome (I doubt I get any detectable benefit from them). Thankfully, Pat updates configs quite often. As it stands, I've been using 3.10.17 since late October, and it's been highly stable, so I won't upgrade until a truly grave security or stability issue is discovered, such a critical ext4 bug.

I tend to stick to the kernel I build my SVN of LFS with which is usually the latest stable kernel. After that, it is only recompiled as needed to add modules or features. When I used Slackware, I stuck to whatever the -Current tree kernel was.

You can make your system run at it's best if you use all the hardware you have in it. So your system will always be as fast as your hardware is, or slower if there are some bugs in the system. Generally you can change the Kernel ( the heart of your system ) if you try to use some new feature that it has been implemented into it. Let's say if you run some new fancy laptop you should use a 3.2 <= Kernel .
Also you should update your kernel if there are some important security concerns, some bugs, or incompatibilities with something ...
A good place to learn more about the Kernel is at his home : https://www.kernel.org/ . Be sure to read the changelogs if you are interested to see what bugs have been fixed and other stuff.

I'm usually satisfied with the generic kernel. I've only tampered with it once, that was before Slack64 came out, to get it to "see" more than 3.2 GB RAM.

I always "roll my own" and usually the latest of the series that comes with
Slackware. Sometimes there are some speed benefits if you include only drivers
and options necessary for your machine (and use).

Even the "generic" kernel is a pretty big beast with frame-pointers, tracers and
lots of debug stuff. Very useful if something goes bad and you have to find out
what happened.

I don't want that functionality. I usually just do a
make allnoconfig && make menuconfig and fill in the stuff that's necessary.
If I don't need modules I make it monolithic. These days with the nouveau driver
I don't see any real reason not to.

Is there a difference? Well I've done some tests. I found a small benchmarking
program here: http://www.unix.com/source/bm.zip. If you want to run it, just unpack
an execute ./Run, takes about an hour. Don't even try to compile anything in there.
The code is ancient and gcc barfs immediately. Some of the tests wont complete
correctly, I've included the ones that do.

Tests on 'generic' (with the deadline scheduler):

BYTE UNIX Benchmarks (Version 3.11)
System -- Linux 3.10.17 #1 SMP Wed Oct 23 2013
x86_64 AMD Phenom(tm) 9650 Quad-Core Processor AuthenticAMD
GNU/Linux
Start Benchmark Run: Mon Jan 6 2014.

Dhrystone 2 without register variables 12299645.3 lps (10 secs, 6 samples)
Dhrystone 2 using register variables 12471500.5 lps (10 secs, 6 samples)
C Compiler Test 979.3 lpm (60 secs, 3 samples)
Dc: sqrt(2) to 99 decimal places 119317.6 lpm (60 secs, 6 samples)
Recursion Test--Tower of Hanoi 117369.4 lps (10 secs, 6 samples)
System Call Overhead Test 2569626.8 lps (10 secs, 6 samples)
Pipe Throughput Test 1544249.7 lps (10 secs, 6 samples)
Process Creation Test 9651.5 lps (10 secs, 6 samples)
File Read (10 seconds) 4786429.0 KBps (10 secs, 6 samples)
File Write (10 seconds) 1324905.0 KBps (10 secs, 6 samples)
File Copy (10 seconds) 122986.0 KBps (10 secs, 6 samples)
File Read (30 seconds) 4776556.0 KBps (30 secs, 6 samples)
File Write (30 seconds) 1162625.0 KBps (30 secs, 6 samples)
File Copy (30 seconds) 84572.0 KBps (30 secs, 6 samples)

Tests on a monolithic kernel (deadline scheduler):

BYTE UNIX Benchmarks (Version 3.11)
System -- Linux 3.10.25-mono #1 SMP Mon Jan 6 2014
x86_64 AMD Phenom(tm) 9650 Quad-Core Processor AuthenticAMD
GNU/Linux
Start Benchmark Run: Mon Jan 6 2014.

Dhrystone 2 without register variables 12222226.7 lps (10 secs, 6 samples)
Dhrystone 2 using register variables 12313789.8 lps (10 secs, 6 samples)
C Compiler Test 1004.3 lpm (60 secs, 3 samples)
Dc: sqrt(2) to 99 decimal places 129666.7 lpm (60 secs, 6 samples)
Recursion Test--Tower of Hanoi 129083.8 lps (10 secs, 6 samples)
System Call Overhead Test 2633972.7 lps (10 secs, 6 samples)
Pipe Throughput Test 1574751.0 lps (10 secs, 6 samples)
Process Creation Test 9394.2 lps (10 secs, 6 samples)
File Read (10 seconds) 5439652.0 KBps (10 secs, 6 samples)
File Write (10 seconds) 1368310.0 KBps (10 secs, 6 samples)
File Copy (10 seconds) 125975.0 KBps (10 secs, 6 samples)
File Read (30 seconds) 5509959.0 KBps (30 secs, 6 samples)
File Write (30 seconds) 1202322.0 KBps (30 secs, 6 samples)
File Copy (30 seconds) 84547.0 KBps (30 secs, 6 samples)

The main difference seems to be in the memory subsystem (files get cached
pretty much instantly with 4G ram). Read speeds are significantly higher.

I guess I'll stick with this one.

I rebuild my kernel with the CK/BFS patch. I don't know that it performs any better than the generic kernel but the BFS scheduler is designed for better interactivity and lower latencies, which I think is important. I also make my kernel preemptible and I turn off dynamic ticks as recommended by Con Kolivas.

I built the 3.12.6 kernel. It boots a bit faster than the -huge kernel I used previously, and: YouTube videos with pipelight run smoother than before. They weren't really choppy, but the image would stand still for a short period of time occasionally. I don't know if it's because I set CONFIG_PREEMPT (I chose low-latency desktop) or because of the newer kernel, but it's a nice improvement.

For a standard Slackware kernel there are some optimizations you could do:

1. Set the CPU family to match your actual CPU instead of CONFIG_M486 or CONFIG_MPENTIUMIII.

2. If you're on a desktop, you could rebuild the kernel with CONFIG_SCHED_AUTOGROUP enabled. It doesn't give you more throughput, but should result in a more responsive user experience. Same goes for CONFIG_PREEMPT.

3. If you're on Slackware 32 bit (for any reasons), you could install a 64 bit kernel. On machines with more than 1 GB RAM this results in better performance.

4. You could replace in-kernel drivers with better performing external drivers, like r8168, nvidia and fglrx.

That's it basically. On a modern PC there is no point in building a "minimal kernel" or using weird compiler flags.

Number 4 is going to be a good debate due to the politics of those drivers. However, drivers from an OEM source being official will carry better scheduling and timing factors than the normal open source derivatives, at least until they catch up.