As I recall, Paul tested using tcmalloc or some other allocator to replace apr_palloc(). No bueno.
The short answer is that pool-based allocation is *wicked* fast, compared to any other attempt/mechanism for allocating memory. I managed to improve over apr by removing an if-test or two, but any other approach will be comparatively/miserably slow. Now, that said: it sounds like you're not asking about apr_palloc(), but really about apr_pool_create(). I believe that would likely be just fine for something like HTTPD. On a per-request basis, it doesn't really allocate many pools. But Subversion tends to create a pool for any for-loop that might allocate memory. *Thousands* get created/destroyed across some Subversion operation. On the client, another microsecond isn't going to be a big deal, but the server exhibits this behavior too. Is your goal to remove the burdens, and simplify the codebase? Or .. ??? Cheers, -g On Wed, Sep 3, 2014 at 2:37 PM, Jim Jagielski <j...@jagunet.com> wrote: > Yeah, that thread, and Greg's work w/ pocore, are kind of > the origins of this question. The thing is that awhile ago, > (I mean way awhile ago), I recall us trying to simply replace > pools w/ malloc/free (Paul was the main dude in this case) > and we got terrible performance... > > It's now ~6 years later and so wondering if just bypassing > the pool freelist is now viable, at least as a compile-time > (or allocator) option. > > On Sep 3, 2014, at 3:11 PM, Ivan Zhakov <chemo...@gmail.com> wrote: > > > On 2 September 2014 16:02, Jim Jagielski <j...@jagunet.com> wrote: > >> Has anyone looked at simply disabling the apr_pools freelist > >> totally lately and seeing what the performance is? > > This thread may be interesting: > > http://svn.haxx.se/dev/archive-2008-10/0070.shtml > > > > We also tested disabling apr_pools free list in our Subversion > > distribution for Windows and didn't noticed performance problems on > > simple tests. We didn't performed proper benchmarks and decided to > > keep standard APR pools, but with very low MaxMemFree value. > > > > -- > > Ivan Zhakov > > > >
