Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: Optimization, modern C and APR 2.0 onwards
From: Jim Jagielski <jim@jaguNET.com>
In-Reply-To: 
 <CACsi252wVqnzOXSrpDd7LEjx6KK=uOf=uDo5OsqiqCYtn0F6-A@mail.gmail.com>
Date: Fri, 20 Nov 2015 14:00:11 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <AFCE62E6-26A0-4C91-933D-875F3B8CA2B7@jaguNET.com>
References: 
 <CACsi252wVqnzOXSrpDd7LEjx6KK=uOf=uDo5OsqiqCYtn0F6-A@mail.gmail.com>
To: APR Developer List <dev@apr.apache.org>

If we are serious about having a serious update to APR, I
would recommend that we use more up-to-date data structures,
patterns and algorithms than those in apr1. For example,
Greg's pocore mini lib is an example of the types of improvements
we should consider.

> On Nov 20, 2015, at 1:31 PM, William A Rowe Jr <wrowe@rowe-clan.net> 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).
> 
> Thoughts?
> 
> Bill