On Fri, Apr 06, 2001 at 03:10:40PM -0700, Ross Harvey wrote:
> 
[earlier blather omitted]
> Furthermore, I just so wish that people could be prevented from handwaving
> about efficiency without even having an argument in the first place. If
> speed is in fact a concern, don't say "might add" or "as efficient as
> possible". Say it WOULD be too slow, say why if it isn't obvious, and be
> prepared to defend it.

And what is *this* crap, except FUD?  Please follow your own advice!

> But since you brought it up, and looking at vn_write(), all I see is a few
> bits of (fixable) code to translate F* flags into IO_* flags, a call to a
> totally nulled-out nqnfs op, and some lock code that you need anyway. Then
> there is another indirect procedure call, but a quick test (note: no hand
> waving) shows that doesn't matter:  kernel and pipe ops take about 11 uS
> on my old eb164 alpha, so a matter of nanoseconds for another level of
> procedure call through a pointer shouldn't matter.

Sure.  You piss away 1uS here, 1uS there, and soon your pipe
implementation is as slow as what we currently have.  The point here is
that PIPES ARE A CRITICAL PATH, and that means yes, you cut corners if
you have to to make it faster.  Just like you cut corners on context
switch and system call entry to make them faster, and the IP input and
forwarding path.

And don't think a VOP_WRITE() call is `just' a normal function call.
Maybe you should look at what that macro actually does.

Let's turn it around.  I'm utterly sick of people touting `architecture'
as an excuse for writing increasingly slow code.  Especially when the
`architecture' arguments are at BEST dubious.