httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: Some memory usage optimizations
Date Sat, 26 Jun 2010 19:29:03 GMT
On 6/26/2010 1:49 PM, Stefan Fritsch wrote:
> Hi,
> 
> there are some places where httpd uses more memory than necessary, 
> which can increase cache misses and reduce performance on current 
> hardware. Things I would like to change:
> 
> 1) reorder structs to have fewer holes on 64bit arches
> 
> Pro: Examples for space savings on 64bit:
> 
> Con: In some cases reordering the struct members makes the code harder 
> to read because related members may no longer be grouped together.

Feel free to reorder for more-optimal storage, but please don't completely
disassociate related fields!  It makes debugging a pain in the neck.  For
that matter, lots of those 'add these to the end of the struct' fields should
be reordered anyways now that we are going towards 2.4.

This still needs to be human-readable.

> 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.

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.

> 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.


Mime
View raw message