Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 20820 invoked by uid 500); 5 Dec 2001 16:44:22 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 20809 invoked from network); 5 Dec 2001 16:44:21 -0000 Date: Wed, 05 Dec 2001 08:41:06 -0800 From: Brian Pane Subject: Re: Pools rewrite [2] To: dev@apr.apache.org Message-id: <3C0E4E22.1070801@pacbell.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 References: X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Sander Striker wrote: >So, actually, there isn't much difference between the plain apr_pcalloc >implementation and the apr_pcalloc macro? (other than code duplication) > >The real solution seems to be eliminating apr_pcalloc calls when possible >(and sensible). Maybe we can have another quantify run to identify the >most prominent left? Brian? > I've done some profiling recently, and there aren't any obvious candidates for apr_pcalloc elimination left. We've fixed the big ones already, and the cases that remain are apr_pcallocs of relatively large structures where only a small subset of the fields are overwritten right after the pcalloc. The creation of request_recs is a good example. --Brian