On Wed, Oct 1, 2008 at 11:11 AM, Ben Collins-Sussman <[EMAIL PROTECTED]> 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
