apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <p...@querna.org>
Subject Re: Poor performance with new apr_pool
Date Thu, 26 Mar 2009 17:24:25 GMT
On Thu, Mar 26, 2009 at 6:05 PM, Branko Čibej <brane@xbc.nu> wrote:
> 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*

That is only talking about loading tcmalloc using the normal library.

you can compile tcmalloc to not use the malloc symbol -- APR would
have to compile it with different symbol names if we were to bundle
it.

Mime
View raw message