httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject Re: _selfish_ NT development requests
Date Wed, 15 Mar 2000 15:56:10 GMT
I'll bite...

> The M$ compilers are very flexible in permitting precompiled headers to
> streamline compilation.  The bulk of the pain seems to be in apr_config.h
> and httpd.h.

I've not used precompiled headers, so maybe I don't know what I'm missing,
but it seems the goal is to compile the code faster. I'm perfectly content
with how fast the code compiles on my 700MHZ Athlon. Apache is not really
that large a project and I am not in favor of expending effort to make it
compile faster. Not a good use of our time, especially if it adds to the
complexity of the codebase. I am already not too happy with the complexity
of the 2.0 Windows port  (async AcceptEx, completion ports, seperate code
paths for Win95/98 and NT/2000, etc.), but this is an absolute necessity to
achieve performance comparable to Apache on Linux.

> This has the added benefit that NT (along with any other platform that
> along requiring the API_EXPORT___ macros) can use a set of CORE_EXPORT___
> equivialants, the apr lib can use a set of APR_EXPORT___ macros, etc...
> The dllimport/dllexport pseudo-pragmas really impact the load time,
> and variable resolution and fixup code.  When it's a known dllimport, the
> linker can call by reference rather than calling a thunk that calls by
> reference.  Getting these cleaned up not only solves mod_info GP faults,
> optimizes the heck out of the whole package.  I imagine (but could be
> that OS2 has some similar benefits.

APR needs to be updated with APR_API_EXPORT (or whatever we decide to name
it) wrappers similar to Apache's API_EXPORT wrappers to eliminate the thunk
overhead. I worked on this a bit before ApacheCon.

Just a general open-source development rule-of-thumb (sorry, sometimes I get
the irresitable urge to get on my soapbox :-),  If you are faced with a
design decision that will incrementally improve performance (or add a
marginal new feature, etc) at the considerable expense of simplicity,
simplicity wins. Most open source projects are staffed by volunteers who do
not typically have the time or inclination to master a complex codebase
before they can start making contributions.


View raw message