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
