On Mon, Nov 23, 2015 at 1:42 PM, Ruediger Pluem <rpl...@apache.org> wrote:
> > On 11/20/2015 07:31 PM, William A Rowe Jr wrote: > > I'm wondering how the group would react to refactoring some of APR 2.0 > > to either offer inline code for many of our heavily consumed functions, > > or offering inline + fn implementations alongside one another? > > > > Would it still be necessary in this day and age to support C compilers > > that do not support inline at all, e.g. hide the inline declarations > based > > on some macro switch leaving only the function stub? > > > > We can obviously debate the merits of which functions are most > > prime for optimization, including how mature each is (due to the > > fact that the user will be 'stuck' with the implementation until they > > recompile their own code against a new release of apr in the event > > of a bug or security fix). > > Especially in case of security fixes it would be a real pain to require > all consumers of the library to recompile. This is one of the beauties of > dynamic linking :-). > So I would like to see it limited to very stable functions that exist for > a long time unmodified > and that have a small code base or we should give the developers a choice > by offering > both ways (inline + fn). > I think that's inevitable (offering the choice). Florian reminded me that compiler support of inline as well as compiler support for partially declared structures will probably be necessary to optimize the code. So we have at least two feature tests (and a combined resulting APR_USE_INLINED macro) that controls whether this is available, and one that should be easily disabled on a source-by-source basis. We will still have to leave more complex code in the library, not exposed to in-lining. But I expect the most significant optimization to come from some of the simplest functions, keeping the complexity of APR mostly opaque to the consumer's sources.
