httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: misc profiling comments
Date Sun, 11 Jan 1998 20:57:21 GMT

On Sun, 11 Jan 1998, Paul Sutton wrote:

> On Sun, 11 Jan 1998, Dean Gaudet wrote:
> > On Sun, 11 Jan 1998, Dean Gaudet wrote:
> > > Here it is if you want to play with it.  This seems to cut the strcasecmp
> > > calls in half. 
> > 
> > Uh here it is for real. 
> > 
> > BTW this also includes code cleanup elsewhere in the server because
> > there's various code that assumes that a table * is the same as an
> > array_header *... despite the existance of the table_elts() routine.  Even
> > though the current implementation does "typedef array_header table" it's
> > not required to be that way... which is why table_elts() exists in the
> > first place. 
> Yep, this all seems to work. But it doesn't seem to make much of a
> difference in performance on my system. I testing requesting an index file
> (/) 1000 times. In fact, I couldn't really such much difference at all --
> there was more variation between subsequent runs of the same httpd than
> between the httpd before and after this patch. Maybe my test case doesn't
> exercise table_set enough? 
> But I'm definitely in favour of fixing up the the use of tables and
> arrays without with table_elts(). 

Yeah I'm not sure my current approach is worth it... I didn't see much of
a difference either. 

One thing I was considering is to have a special structure for
r->headers_in, when we populate r->headers_in we notice when the string
matches one of the headers we're interested in (i.e. "If-Modified-Since",
"If-Unmodified-Since", ...) and slap it into a vector as well as the
table.  To do this requires only one hash (using a perfect hash).  Then
later in the code we can use an enumerated type to find the values.

But that's a lot of work.  I'm not likely to do it.

But yeah I'll extract the parts of the patch which are a table API


View raw message