Paul Querna wrote: > On Thu, Mar 26, 2009 at 6:05 PM, Branko Čibej <[email protected]> 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
