apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: Pool freelist
Date Thu, 04 Sep 2014 07:35:31 GMT
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 .. ???


On Wed, Sep 3, 2014 at 2:37 PM, Jim Jagielski <jim@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 <chemodax@gmail.com> wrote:
> > On 2 September 2014 16:02, Jim Jagielski <jim@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
> >

View raw message