apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Branko ─îibej" <br...@xbc.nu>
Subject Re: Poor performance with new apr_pool
Date Thu, 26 Mar 2009 17:05:58 GMT
Paul Querna wrote:
>> FreeBSD 7.1-STABLE (amd opterons; people.apache.org):
>> APR 1.3: 242582048
>> APR 2.0: 537562071 (+221%)
>>     
>
>
> Same FreeBSD 7.1 machine, using tcmalloc[1]
> APR 1.3: 243307182
> APR 2.0: 214131712 (-22%)
>
> I think we should consider bundling tcmalloc, or making it a compile
> time option.
>   

    For some systems, TCMalloc may not work correctly on with
    applications that aren't linked against libpthread.so (or the
    equivalent on your OS). It should work on Linux using glibc 2.3, but
    other OS/libc combinations have not been tested.

*shudder*

and:

    Don't try to load TCMalloc into a running binary (e.g., using JNI in
    Java programs). The binary will have allocated some objects using
    the system malloc, and may try to pass them to TCMalloc for
    deallocation. TCMalloc will not be able to handle such objects.

We have JNI bindings for Subversion, which uses APR, whose packaging and
compilation options we don't control. *boom*

So tell me again, why do you have to rip out perfectly good pool code
and replace it with something slower and/or less portable?

> This shows that many libc have crappy malloc....
>   

Why am I not surprised? :) Come on, we've known that for ages, it's one
of the major reasons why we have pools in APR.

-- Brane

Mime
View raw message