On Wed, Oct 1, 2008 at 11:11 AM, Ben Collins-Sussman
<sussman_at_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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-02 09:22:21 CEST