stack depth perusal

[Dean Gaudet <dg...@arctic.org>]

Of concern for threaded apache is the depth of the stack (well it's a
concern for non-threaded apache).  It has a direct effect on the size of
the process, and the amount of L1/L2 cache used.  I was really worried
about the number of "char buf[MAX_STRING_LEN]" which were scattered
around the code... but now that I've dug into it, things aren't as bad
as I thought.

I cleaned up a few stragglers in apache-nspr which didn't really need the
buffer (could use other mechanisms which may not have existed when the
code was written).  Here's what's left:

config file reading:
    There's scads of code which uses ap_getline() and ap_bgets() to
    read configuration files a line at a time.  To do this they need an
    on-stack buffer... more often than not they end up using ap_getword()
    and similar routines which just copy things out of the buffer,
    and they never actually modify the buffer.

    It would be far more efficient to read() or mmap() the entire config
    file, and write a general set of parsing routines to handle the
    contents.  Not only would we save one copy of the bytes (the copy
    from the disk buffer onto the stack); but we'd also remove static
    line length limitations.

misc API routines that force a buffer:
    less important than the previous.

    PR_FormatTime (strftime) and PR_NetAddrToString (inet_ntoa) are two
    examples of routines that force a buffer onto the stack... my proposal
    to fix these is to make printf extensible -- so that we can add formats
    to it as needed (and damn the gcc -Wformat warnings).  For example,
    strftime could be integrated as the %T format, using something 
    like this "The time will be %{%a, %d %b %Y %T GMT}T at the beep."
    ... the stuff between {} is the arg to strftime.  The advantage to
    this approach is that those functions can instantly be used with
    ap_rprintf(), ap_bprintf(), ap_psprintf(), and ap_snprintf().
    Which opens up opportunities to get rid of the on-stack buffer.

mod_proxy:
    I didn't look at it much at all.  But it does seem to have a
    profusion of MAX_STRING_LENGTH.

mod_rewrite:
    Ralf wins the "I like to copy data around and around and around"
    award :)  Consider apply_rewrite_rule().  It has two stack buffers
    newuri[MAX_STRING_LENGTH] and env[MAX_STRING_LENGTH].  For both
    of them there's a bunch of calls to expand_backref_inbuffer(),
    expand_variables_inbuffer(), and so on.  Each of those expand routines
    does a bunch of their work through routines such as ap_pregsub(), and
    ap_pstrdup(), which create dynamically allocated strings... and then
    the results are *copied back* to the static-sized buffer.  And then
    finally when the gymnastics are done, there's a pstrdup(r->pool,
    newuri) and such... which makes one last dynamic copy :)

    Ralf you could probably get a 4X url rewriting speed improvement
    with a little work cleaning this up.

That's it.  It's far better than I thought.  I wouldn't mind getting
dynamic stack depth numbers from folk... I'll see about making a patch
to show it in the scoreboard.

Dean