Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
From: "Sander Striker" <striker@apache.org>
To: "Karl Fogel" <kfogel@newton.ch.collab.net>
Cc: <dev@apr.apache.org>,
	<dev@subversion.tigris.org>
Subject: RE: [PATCH] Pools space-time tradeoff
Date: Thu, 23 May 2002 00:44:05 +0200
Message-ID: <JLEGKKNELMHCJPNMOKHOGEJDFOAA.striker@apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <85g00jua2u.fsf@newton.ch.collab.net>
Importance: Normal

> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> Sent: 22 May 2002 23:50

> Greg Stein <gstein@lyra.org> writes:
>> That algorithm "won't work" ... there is too much searching taking place.
>> The current pools code is way fast because it doesn't have to search for
>> blocks in the typical allocation case.
>>
>> The pools code is quite sensitive. It is noticable if you add even one more
>> 'if' statement to the typical-use codepath.
>> 
>> (the proposed patches don't seem too bad because they really only come into
>>  play at non-typical points: when you need a new block, and when you're
>>  freeing a pool)
> 
> Ah, okay, so the "active block" means "try me first no matter what",
> and the "inactive blocks" are "try us before allocating a new block",
> and the distinction is made for speed.

*nod*
 
> (Except that even with the patch, we'll only try the first of the
> inactive blocks.)

Yes, the first is the one with the largest free space left, since we
keep the list ordered in a simple manner.  There is room for improvement
in that department.  A faster way of keeping the list ordered can be
coded up.  A priority queue might even be a better idea, since we only
need to have the head of the list be the block with the largest amount
of free space.
 
> Hmm.
> 
> I guess I don't know how the benchmarks look, so I'll shut up now :-).

*grin*


Sander