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 20:32:49 GMT
Paul Querna wrote:
> 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.
>   

I don't get it. You threw out one allocator implementation, replaced it
with another one that uses malloc with higher granularity, now you're
thinking about bundling a fast malloc implementation to fix the
performance regression that your first change caused.

Maybe it's just me, but all that seems like a monumental waste of time.

-- Brane

Mime
View raw message