Subject: Re: But why?
To: David S. Miller <davem@caip.rutgers.edu>
From: Perry E. Metzger <perry@piermont.com>
List: tech-kern
Date: 10/23/1996 15:45:29
"David S. Miller" writes:
> So true.  Especially as of late my stream of consciousness has been
> "geese, it has been almost two days since I was able to suck a couple
> hundred cycles out of a major critical code path, I'm slacking off
> again."

Is it just me, or does this sort of activity strike anyone else as
being a phenomenal waste of time?

Lets take my favorite O/S, for the moment: NetBSD. It has some serious
problems in it -- the VM subsystem isn't all it could be, we lack
support for some peripherals, it would be nice to clean up the install
system... indeed, plenty is wrong.

There are lots of far better places to spend one's time, in other
words, than on microoptimizations. The microoptimization work I do
support is on improving the compiler, since that helps everything at
once.

To summarize, I've never once awakened in the night to think, "My god!
system calls take too many microseconds! Why, a tight gettimeofday()
loop runs way too slow!" Occassionally, I wake up and think "it would
be neat to make system installation easier".

The few places where there are noticable performance issues in NetBSD
have all been data structures and algorithms issues. Replacing linked
lists with hash tables and such wins far more there than random
tweaking helps you with. An IP stack that never copied data might help
performance as we move to gigabit networks, but shaving system call
setup down isn't going to.

Microoptimization is sometimes a fun game -- look at what Phil Karn
has done with his machine code implementation of DES, for
example. However, on my machine, the kernel's performance isn't in
general what ails me.

Perry