On Fri, Dec 4, 2015 at 10:17 AM, Nick Kew <n...@webthing.com> wrote: > > > I'm looking, none of these seem like huge hacks, wondering > > which of them trigger your concern? > > Well, your talk of refactoring config led me to wonder > whether you were proposing another tilt at the whole directory > walk stuff. While that may have merit, past experience > tells us it's not going to be easy! >
If I never have to refactor that code again, it will still be too soon :-/ More likely that someone enthusiastic could take the base/short unique <Directory> blocks and pre-merge those to global/vhost scope, as the shortcut to a more specific scope as the first-match hit. Deeper pre-merge optimizations would be rough and all of it presupposes there are no request-specific eval blocks and no directory permitting an .htaccess could be optimized that way. So... no... much like the non-iterating fnmatch implementation, I'd prefer to let others wrap their heads around that puzzle and come up with something new and more efficient. All I was thinking of doing was extending the core concept of 'compiled in modules' to allow a module-of-modules, and build unique create/merge call tables at the end of register_hooks, instead of the slightly odd way we we presume that each module does or does not have one of each such creater/merger, skipping along the NULL refs. When we last tried to optimize this, hooks were attempted and proved to have much too much overhead. A startup-time straight array of function pointer/conf index pointer elements will be the only way to keep the logic as efficient as it is today, and then build upon that model. I don't expect we will allow the create/merge table to change after the register_hooks phase.
