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.
Regards,
Graham
--
