Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 63122 invoked by uid 500); 22 May 2002 19:35:07 -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 63106 invoked from network); 22 May 2002 19:35:06 -0000 Date: Wed, 22 May 2002 14:33:37 -0500 (CDT) Message-Id: <200205221933.g4MJXbE92207@newton.ch.collab.net> From: Karl Fogel To: "Sander Striker" Cc: , "SVN Dev List" Subject: Re: [PATCH] Pools space-time tradeoff Reply-To: kfogel@collab.net X-Windows: there's got to be a better way. X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Btw, when I wrote this > - When palloc() requests some mem, see if there's any block with > enough unused room to handle it. If so, allocate in that block. ... I didn't specify whether one should use the block with the smallest free space that still satisfies the request, or the largest, or some other algorithm. Frankly I'm not sure how fragmentation plays out in real life :-). My instinct would be take the smallest and just live with the little bits of unused memory, but maybe in practice it turns out to be better to take the largest, so one still has a significant amount left over in that block even after the allocation? -K