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

Just you.

> 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.

Well, you may be right.  But why put our microoptimization kernel
hacker to do installation programs if we have a team of experts doing
that?  We just happen to have a bunch of volunteers that split up the
job and do what they are more insterested in.  The issue at hand is
that our optimizating leader just got us more computer cycles for
userland applications.

> 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".

Well, Jakub Jelinek, just got us a strcpy that is 5 times as fast as
the one we were using on all of our userland, I find that kind of
optimization nice.  This guy, is also responsible for getting us 2
more instructions for userland applications per subroutine call in
shared libraries.  Add them up thousands of times.

> 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.

Alan Cox just devised a way for Linux/SPARC to avoid packet copying on
our networking stack, another optimization coming to our SparcLinux
tree.  Imagine, for a 10 meg ftp transfer, we will be giving our users
a bunch of free clock cycles on their machines.

Miguel.