httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: [PATCH] performance fix for mod_include
Date Sat, 10 Nov 2001 06:32:00 GMT
On Friday 09 November 2001 09:56 pm, William A. Rowe, Jr. wrote:
> From: "Brian Pane" <>
> Sent: Friday, November 09, 2001 11:20 PM
> > In mod_include, we use apr_pcalloc to create an include_ctx_t,
> > which consists of about 80 bytes of integer and pointer fields
> > and a pair of character buffers used to hold strings.  Each
> > of the character buffers is 8KB...
> >
> > calloc'ing all this space accounts for about 9% of the total
> > usr-mode CPU time in the httpd.
> >
> > This patch zero-fills just the integer and pointer fields in
> > the structure, plus the first byte of each of the string buffers.
> > With the patch, I'm seeing a 19% improvement in SSI throughput
> > in informal testing (ab running a single request at a time,
> > over the loopback on Linux).
> +1... but I do question the size of those buffers... they seem
> inordinately large and wasteful.  If we have an error, why not
> simply a char* that can be alloc'ed once needed?
I'll do you one better.  The error string, if you look through the code, is copied
on the first call to the filter from a per-dir config structure.  Then it is parsed,
and turned into a bucket.  That seems incredibly wasteful.  Why do we copy
it at all, the only time we use that string anywhere it is a const char *.  We
could very easily just pass the string directly from the per-dir config structure.
BTW, all of that applies equally to the time_str variable too.  Those string
copies are only done when they are needed, but still, why copy if we don't
need to.  So, I am +1 for applying the patch, but I think there is a lot more work
that could be done to improve mod_include.  :-)


Ryan Bloom
Covalent Technologies

View raw message