> From: Karl Fogel [mailto:[EMAIL PROTECTED] > Sent: 22 May 2002 23:50
> Greg Stein <[EMAIL PROTECTED]> 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
