httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: cvs commit: httpd-2.0/modules/http http_protocol.c
Date Sun, 14 Oct 2001 16:40:37 GMT
(a little late, but...)

On Thu, 11 Oct 2001, Aaron Bannert wrote:

> On Thu, Oct 11, 2001 at 12:18:39PM -0400, Cliff Woolley wrote:
> > On Thu, 11 Oct 2001, Aaron Bannert wrote:
> > 
> > > I believe you are mistaken. It is an optimization of a compiler to try to
> > > preallocate the stack if it can determine the max stack size, but it can
> > > not always be determined until runtime:
> > >
> > > int main(int argc, char *argv[])
> > > {
> > >     int i;
> > >
> > >     for (i = 0; i < argc; i++) {
> > >         int j[argc];
> > 
> > Well, that's obviously different than the case we're talking about here,
> > which has a pre-determined, fixed length.
> My point is we can't make those kind of broad assumptions about our
> compilers. One of the strengths of Apache is it that it runs just about
> everywhere, and if it doesn't you can probably port it easily. These kind
> of things just make the porting effort more difficult, or even worse,
> cause subtle performance hazards.

Umh... the above code isn't at all portable anyway, since it was only
introduced in very recent standards, so talking about "assumptions about

Using features such as the above that aren't portable make porting
more difficult, sure.  

That is a very different thing than saying we should try to
micro-optimize the code to generate the fewest possible (or "best"
possible instructions, since instruction count and execution time
are only very loosely related) instructions when compiled on the
dumbest possible compiler.  It is NOT a "broad assumption" to assume
that, given common code constructs, the compiler will generate code
that is reasonably efficient.

Should we do our own loop unrolling "just in case" the compiler doesn't
do it?  Of course not, since that just makes the compiler's job harder
and isn't appropriate in all conditions.  That's for the compiler to worry

> > We do this sort of thing _everywhere_ in the code.  We have to assume at
> > least a thing or two about the compiler being non-stupid.  But even if it
> > is stupid, tighter scoping of temporary variables like this from time to
> > time (a) makes it easier to find the declaration of the thing, especially
> > in a long function and (b)  keeps you from fscking up and stepping on
> > yourself later.
> I completely agree with you that tighter scoping of temp variables is
> good defensive programming, but this is not an appropriate way to convey
> that. A more precise approach might be to do this:
> func() {
>     ...;
>     {
>         apr_off_t foo;
>         while (c) {
>             foo = ...;
>         }
>     }
>     ...;
> }

Anyone who is concerned about the trivial performance difference
between the two is silly to be using a compiler that doesn't handle
such trivially basic optimizations (well, actually, it would probably
take a compiler with a very odd subset of optimizations to do bad
things with such code, since generally the naive implementation
doesn't cause shrinking/growing of the stack in this case).  The
complexity of a compiler doesn't come from simple code generation,
it comes from optimization, and I'd think you would be hard pressed
to find a compiler where this particular issue made any difference.
Heck, in some cases the variable will be completely optimized out
of the generated code anyway.

More to the point, when you start going down this road, you often end up
just making things harder for the compiler by deconstructing common
constructs that it knows how to best optimize into a more general 
construct that it can't deal with as well.  And knowing just what is 
"optimal" in the generated assembly is extremely difficult given
the complexity of and differences between modern (ie. even 5+ year
old) processors.

Readability and ease of maintainability are, by far, the #1 critera here.
The above construct says to me that we have a variable which we are 
using across invocations of the loop.  Because that is the scope it was
explicitly given.  That is a very different thing than a variable used
within each invocation of the loop; the proper way for the code to 
state this is for it to be declared within the loop.

View raw message