apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: [PATCH] Pools space-time tradeoff
Date Wed, 22 May 2002 17:36:13 GMT
> From: sussman@collab.net [mailto:sussman@collab.net]
> Sent: 22 May 2002 19:16

> [crossposted to APR and SVN dev lists.]

[...]
> ** Here's the solution:
> 
> Sander whipped out two of his pool patches that have been previously
> ignored up till now.  He combined them into a single patch.  Here's
> what they do:
> 
>   1.  Keep each pool's list of 'old' active blocks sorted by size.  If
>       a request comes in that won't fit in the current active block,
>       then try to alloc the request in the largest 'old' active block
>       (instead of alloc'ing a completely new active block).
>       Effectively, we get some memory re-use now.
> 
>   2.  When a pool is destroyed or cleared, normally all of its
>       inactive blocks are given back to a 'global free list' in the
>       pool hierarchy.  We now have a threshold size that can be set:
>       if the global-free-list ever grows larger than the threshold,
>       then the 'extra' inactive blocks are actually free()d.  We've
>       set the maximum free-list size at 4M for now.
> 
> Anyway, I've included the patches below for people to look at.
> Apparently Sander posted these before, but nobody had a reason to
> care.  Well, now Subversion *really* needs these features.

Well, I need to clarify that the high free patch has come up before
and a small group of people wanted it included (ianh and brianp iirc).
I didn't commit it since the demand was too low and I was +0 myself.
Seeing the impact it has on subversion and the fact that the developer
has control over the threshold (which defaults to unlimited, so no
surprises there), I've decided to go ahead and commit this change
within a day or two unless major objections are raised.
 
> I've tested this patch on our two use cases: the memory footprint for
> 'svn checkout' bounces up and down, but eventually plateaus around
> 25M.  The footprint for 'svnadmin dump' also bounces around, but
> plateaus around 17M.  A huge difference! 
> 
> Sander is worried about possible pool-performance hits from these
> changes, so he's hoping folks might be able to do some timing stats.
> (Personally, via my sophisticated use of the unix 'time' command, I
> find no noticeable difference.)

Ian, Brian, or anyone else doing thorough benchmarks, could you please
run some benchmarks on httpd with and without the patch?

Thanks,

Sander

Mime
View raw message