httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: [PATCH] directory_walk and relatives performance improvements
Date Sat, 08 Feb 1997 02:26:16 GMT
+1.  Also has a +1 from Randy and Chuck, so I will commit it later 
tonight unless anyone objects...

On Sun, 2 Feb 1997, Dean Gaudet wrote:

> I decided to do some gprofs of the server.  I'm pretty sure that when
> Randy did it before (it was Randy right?) we got bogus results because
> when a fork() happens the child inherits all the parent's current profile,
> so lots of stuff get overcounted.  So for my profiling I chose just
> to run with -X.  My test set was 1000 requests from the access log on
> www.arctic.org ... which is mostly static files with a few SSI.
> 
> The profile before optimizing:
> <http://www.arctic.org/~dgaudet/apache/gprof.pre-optimize>
> 
> Notice the heavy use of pstrcat() by make_full_path().  A quick look at
> directory_walk() shows that the call to make_full_path() is to initialize
> an auto variable... a variable which is only used in one obscure if()
> much further down into the function.  auto initializers are evil!
> I cleaned this one, and a few others while I was at it.
> 
> Notice the heavy use of is_matchexp() inside directory_walk() (and its
> relatives).  It's being called on a string that is static after config
> time, so I added the member d_is_matchexp to core_dir_config and set it
> appropriately at config time.
> 
> Then I generated another profile:
> <http://www.arctic.org/~dgaudet/apache/gprof.optimize>
> 
> Massive time spent in merge_core_dir_configs().  After eyeballing it I
> noticed the section that merges the response_code_strings[].  There are now
> 38 response codes (there were only 10 in 1.1), so this is expensive.  I'm
> guessing that most people don't modify the response codes on a per
> directory basis... so I optimized it as follows:
> 
>     char *response_code_strings[RESPONSE_CODES];
> 
> became:
> 
>     char **response_code_strings;
> 
> And it isn't allocated until one of them is set.  This let me speed up
> the merge.
> 
> The final profile is at:
> <http://www.arctic.org/~dgaudet/apache/gprof.optimize2>
> 
> Some areas I looked at but didn't touch include
> 
> - tweaking directory_walk() to avoid repeated calls to make_dirstr()
>     (and its associated palloc()s) -- do one allocation at the beginning
>     and screw with the string as you go
> 
> - implementing a simple hash for tables -- no buckets, just a bit vector.
>     If the bit is 0 then you can short circuit the scan through the
>     table when adding/merging.
> 
> - instead of scanning the array of modules each time a handler needs to be
>     invoked, build linked lists of only the non-NULL handlers at config time.
>     There are an awful lot of NULLs in the array which are a waste of time.
>     run_method is up there in the final profile... so this should be a win.
> 
> I wish I had real profiling tools... like something that would give me
> sampling information on a line basis.  (but linux tools suck)
> 
> At any rate, here is the patch.
> 
> Dean
> 
> Index: http_core.c
> ===================================================================
> RCS file: /export/home/cvs/apache/src/http_core.c,v
> retrieving revision 1.62
> diff -c -3 -r1.62 http_core.c
> *** http_core.c	1997/02/01 22:03:36	1.62
> --- http_core.c	1997/02/02 08:16:45


Mime
View raw message