httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: Some memory usage optimizations
Date Sat, 26 Jun 2010 22:27:24 GMT
On Saturday 26 June 2010, William A. Rowe Jr. wrote:
> > 2) Use char instead of int for the module_levels vector in
> > struct  ap_logconfig. The length of the vector is ~100.
> >
> > Pro: This may save ~300 bytes per server conf which are read
> > often and  therefore occupy CPU-cache memory
> >
> > Con: On some architectures, accessing chars is slower than
> > accessing  ints.
> >
> > Does anyone have an idea what is better, here? Int or char?
> >
> > The same argument could be made for boolean flags in various
> > other structs. But I don't think those are worth the effort.
> 
> Anytime it's part of a per-dir, I'd suggest char is probably
> better, or even bitfields.  The shifting pain is equal to slicing
> a char.

Since bit-field ordering is compiler-dependant, I think we should not 
use bit-fields in public headers. In private data, it may be ok. But 
accessing bit fields is even more expensive than accessing chars.

> But we are almost to 128 modules.  So be careful here, let's
> presume that folks continue to propagate specific bits of
> functionality into a module.

To make it clear: I only want to change the elements of the 
module_levels vector which only need to take values from -2 to 15. The 
index used to address the element will of course stay an int.

But trunk has > 110 modules already. Maybe we should increase 
DYNAMIC_MODULE_LIMIT from 128 to 192?

> 
> > 3) In server/config.c, many config vectors are created (allocated
> > and  zeroed) with length (total_modules + DYNAMIC_MODULE_LIMIT).
> > But this is only necessary before dynamic modules are loaded.
> > Afterwards, total_modules is set to the total number of modules.
> > Therefore allocating a vec of length total_modules should be
> > enough. This would save zeroing 128 pointers per request and
> > connection.
> >
> > It seems the attached patch works and I could not find any
> > problems  when adding/removing modules during graceful restart.
> > Objections?
> 
> What of a separate alloc_modules variable, that would be init to
> the old (total_modules + DYNAMIC_MODULE_LIMIT), and could be
> truncated when the pre-config was complete to simply
> total_modules.  This might even save additional
> processing/merging/copying on the stale/unused NULL pointers.

I have commited something like this.

Cheers,
Stefan

Mime
View raw message