filtered I/O tail recursion bad/good?

[rb...@covalent.net]

I dislike tail recursion in any form for filtered I/O.  It is my belief
that the link-design is mutual or indirect tail-recursion.  On some
platforms (not all) this is going to kill our performance.  I believe
(Cliff, please correct me) that Solaris had tail-recursion in their stream
stack architecture, and they saw a huge performance win when they removed
it.  Tail-recursion isn't necessarily a performance killer, but on some
platforms it is, and Apache supports too many platforms to play games with
this, IMHO.

Ryan


_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------

Re: filtered I/O tail recursion bad/good?

[Greg Stein <gs...@lyra.org>]

On Wed, 31 May 2000 rbb@covalent.net wrote:
> I dislike tail recursion in any form for filtered I/O.  It is my belief
> that the link-design is mutual or indirect tail-recursion.  On some
> platforms (not all) this is going to kill our performance.  I believe
> (Cliff, please correct me) that Solaris had tail-recursion in their stream
> stack architecture, and they saw a huge performance win when they removed
> it.  Tail-recursion isn't necessarily a performance killer, but on some
> platforms it is, and Apache supports too many platforms to play games with
> this, IMHO.

I believe this is a red herring.

There isn't a compiler that is going to try to unwind this. I don't even
see a need for a compiler to *try*.

One function calls another, which calls another. The fact that two of the
functions are the same doesn't have any impact on performance that I am
aware of.

Let's consider the standard "observer" pattern where an object notifies
another object. It calls a function to perform the notify. An observer
gets the notification, changes state, and performs its own notify. More
than likely, this is the same function. This pattern occurs often, yet
I've never heard of people trying to unwind the notification process.

The Python interpreter reenters, the C function, PyEval_CallObject()
often, when any function call is performed. The function is parameterized
by the callable object (the Python function object). CallObject yanks out
the VM byte codes and starts execution. If one of those byte codes
performs a function call, we go right back to PyEval_CallObject with the
target of the call. Again: I haven't seen any real performance issues with
this. [people are working on a model that does not intersperse the C stack
with the VM stack so that coroutines are possible, but that is for a
different purpose... not optimization or to fix perf problems]

Can somebody explain (in terms of a processor, resulting assembly, or
whatever) why two instances of ap_lwrite() on the stack is a Bad Thing?

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/