Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 83114 invoked from network); 26 Mar 2009 12:20:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 26 Mar 2009 12:20:21 -0000 Received: (qmail 71195 invoked by uid 500); 26 Mar 2009 12:20:20 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 71121 invoked by uid 500); 26 Mar 2009 12:20:20 -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 71113 invoked by uid 99); 26 Mar 2009 12:20:20 -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 12:20:20 +0000 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [213.191.128.81] (HELO mxout2.iskon.hr) (213.191.128.81) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 26 Mar 2009 12:20:11 +0000 Received: (qmail 7442 invoked from network); 26 Mar 2009 13:19:48 +0100 X-Remote-IP: 213.191.142.122 Received: from unknown (HELO mx.iskon.hr) (213.191.142.122) by mxout2.iskon.hr with SMTP; 26 Mar 2009 13:19:48 +0100 Received: (qmail 6460 invoked from network); 26 Mar 2009 13:19:48 +0100 X-AVScan: ClamAV X-Remote-IP: 89.164.41.238 Received: from 41-238.dsl.iskon.hr (HELO mturk.csb) (89.164.41.238) by mx.iskon.hr with SMTP; 26 Mar 2009 13:19:48 +0100 Message-ID: <49CB72DA.2030401@apache.org> Date: Thu, 26 Mar 2009 13:19:38 +0100 From: Mladen Turk User-Agent: Thunderbird 2.0.0.17 (X11/20080915) MIME-Version: 1.0 To: APR Developer List Subject: Re: Poor performance with new apr_pool References: <49CB671F.9040801@apache.org> In-Reply-To: <49CB671F.9040801@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Mladen Turk wrote: > Just did some quick bench of the current trunk, > and the results are not very much encouraging. > Inner loops are even worse. Calling 10000 x 32 bytes allocations is more then 10 times slower. This takes less then a second on my box to finish with apr 1.4 and 11 seconds with trunk :) for (i = 0; i < 10000; i++) { apr_pool_t *p; apr_pool_create(&p, NULL); for (j = 0; j < 10000; j++) { m = apr_palloc(p, 32); } apr_pool_destroy(p); } Regards -- ^(TM)