httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: svn commit: r1026668 - /httpd/httpd/trunk/modules/proxy/mod_proxy.h
Date Tue, 26 Oct 2010 20:28:39 GMT
On 26 Oct 2010, at 8:52 PM, Jim Jagielski wrote:

> Does this really help out? Certainly years ago bitfields made
> sense but nowadays even K&R say to avoid them.
> Plus, when we have bitfields "randomly" located in the struct,
> padding becomes an issue. Plus, iirc, they are slow.
> I'd be +1 for changing them to chars if we want to save
> space.

Before changing these fields I went on an extended google session to  
find whether there was any specific reason they should be avoided, and  
I didn't find any (that isn't to say they don't exist).

I then looked for existing precedent for bitfields in the httpd code,  
and found this (from httpd-trunk, httpd-2.2):

httpd.h:    unsigned int clogging_input_filters:1;
httpd.h:    unsigned aborted:1;
http_core.h:    unsigned d_is_fnmatch : 1;
http_core.h:    unsigned int allow_encoded_slashes : 1; /* URLs may  
contain %2f w/o being

These are pretty fundamental parts of the httpd core, and if bitfields  
are a problem, we are very likely to have run into problems before  
with these fields, surely?

The drive to optimise this in our particular case is a particular  
class of reverse proxy image filtering server that reverse proxies to  
3500 separate locations (and counting). Every location involves a copy  
of the proxy config, 4 bytes for each "set" field, and that adds up to  
lots of ram not fitting into CPU caches. mod_cache's quick handler  
helps a lot in this case, but it's still not ideal.


View raw message