Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 95996 invoked from network); 26 Mar 2009 17:24:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 26 Mar 2009 17:24:54 -0000 Received: (qmail 12325 invoked by uid 500); 26 Mar 2009 17:24:53 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 12238 invoked by uid 500); 26 Mar 2009 17:24:53 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 12230 invoked by uid 99); 26 Mar 2009 17:24:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Mar 2009 17:24:53 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of paul@querna.org designates 74.125.46.28 as permitted sender) Received: from [74.125.46.28] (HELO yw-out-2324.google.com) (74.125.46.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Mar 2009 17:24:47 +0000 Received: by yw-out-2324.google.com with SMTP id 5so523116ywh.13 for ; Thu, 26 Mar 2009 10:24:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.110.9 with SMTP id n9mr2329042ybm.127.1238088265918; Thu, 26 Mar 2009 10:24:25 -0700 (PDT) In-Reply-To: <49CBB5F6.30601@apache.org> References: <49CB671F.9040801@apache.org> <4239a4320903260549s3679e713u3f314a870e7ad24b@mail.gmail.com> <4239a4320903260632ld52bd4h310853d66c157b5c@mail.gmail.com> <4239a4320903260740l6786164l7d682c4d8a37d59b@mail.gmail.com> <49CBB5F6.30601@apache.org> Date: Thu, 26 Mar 2009 18:24:25 +0100 Message-ID: <4239a4320903261024l4ca2ecd3jd91229f9883602cd@mail.gmail.com> Subject: Re: Poor performance with new apr_pool From: Paul Querna To: =?UTF-8?Q?Branko_=C4=8Cibej?= Cc: APR Developer List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Thu, Mar 26, 2009 at 6:05 PM, Branko =C4=8Cibej 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. >> > > =C2=A0 =C2=A0For some systems, TCMalloc may not work correctly on with > =C2=A0 =C2=A0applications that aren't linked against libpthread.so (or th= e > =C2=A0 =C2=A0equivalent on your OS). It should work on Linux using glibc = 2.3, but > =C2=A0 =C2=A0other OS/libc combinations have not been tested. > > *shudder* > > and: > > =C2=A0 =C2=A0Don't try to load TCMalloc into a running binary (e.g., usin= g JNI in > =C2=A0 =C2=A0Java programs). The binary will have allocated some objects = using > =C2=A0 =C2=A0the system malloc, and may try to pass them to TCMalloc for > =C2=A0 =C2=A0deallocation. TCMalloc will not be able to handle such objec= ts. > > 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.