Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of justin.erenkrantz@gmail.com
 designates 209.85.217.21 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references:x-google-sender-auth;
        b=kD1ROmieWWxihF78xTyYMkhPARHu6nX505MFlVbaGl94wQnaX47ZN2YWkdJUIfqDjZ
         MVa3PG+DIx5iqcwitKURtEfVvORRJDtUIpCZLdzwObGve9sbdUMsoRCTMFYtzdvCqedl
         s2H12k6i6TLalaqUNviuWUUQuIJzSrvtD/eXw=
Message-ID: <5c902b9e0810020022t49d34fbmb5caacd6b24a142@mail.gmail.com>
Date: Thu, 2 Oct 2008 00:22:04 -0700
From: "Justin Erenkrantz" <justin@erenkrantz.com>
Sender: justin.erenkrantz@gmail.com
To: "Ben Collins-Sussman" <sussman@red-bean.com>
Subject: Re: apr pools & memory leaks
Cc: "Subversion Developers" <dev@subversion.tigris.org>, dev@apr.apache.org
In-Reply-To: <53c059c90810011111v37c36635y7279870f9bc852a0@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <53c059c90810011111v37c36635y7279870f9bc852a0@mail.gmail.com>

On Wed, Oct 1, 2008 at 11:11 AM, Ben Collins-Sussman
<sussman@red-bean.com> wrote:
> In the long term, I think we need to question the utility of having
> APR do memory recycling at all.  Back in the early 90's, malloc() was
> insanely slow and worth avoiding.  In 2008, now that we're running
> apache with nothing but malloc/free, we're unable measure any
> performance hit.  The whole pool interface is really nice, but I
> wonder if pool recycling may just be unnecessary on modern hardware
> and OSes.

If you are using a specialized malloc implementation (like Google's
TCmalloc), then it will almost certainly be doing recycling underneath
for you in some fashion.  These packages are largely optional, and I'm
not aware of any OS that has these functionalities enabled by
*default*.  (Solaris and Mac OS X have them available, but need to be
turned on by environment variables or other linker tricks, IIRC.)
However, yes, there are more smarter malloc implementations than there
were 10 years ago...but I don't think it's prevalent enough where APR
should just assume that malloc()/free() is inherently cheap unless it
were to bundle one of those libraries directly.  (Google's TCmalloc is
C++, but there are others that are likely reasonably portable too.)

BTW, implicit in the reason why there is not a noticeable performance
hit with malloc/free off for you is that you probably *are* using
TCmalloc or some special Google library that handles the memory
recycling already.  =)  -- justin