Re: [PATCH] Pools space-time tradeoff

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)

Cheers,
-g

On Wed, May 22, 2002 at 02:33:37PM -0500, Karl Fogel wrote:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org