[interfacekit] Re: BBlockCache bug

> > > 3. To get a buffer, you just return fCache[fMark] and increment fMark.  
> > > This is O(1) which
> > > is good and much better than our current implementation.
> > What happens if fMark is larger than the numbers of existing buffers?
> 
> A new, uncached, one is allocated instead.
Uh, ok, that must be because they are swapped in the save function,
I was slightly confused,

> > > 4. To return a buffer back to the cache, it searches from 0 ... (fMark - 
> > > - 1) and decrements fMark.  Swapping the pointers is a pretty cheap 
> > > operation but finding
> > Bad.
> Why?
Because searching the array is bad, if there doesn't need to be one.

> If you have to search your used list on Save(), it will be O(n), exactly as 
> Be's implementation. Please don't waste you time.
I realized that. Only one list is needed.

Deallocation of buffers should work similar to the Be Book description now.

> What one can do to optimize Save() is not to keep track of the used blocks. 
Yes, that's a pretty good idea.

> That way you simply check, whether the chunk of memory passed to Save() has 
> the right size and, if so, add it to your stack of free blocks. If not, or if 
> the cache has reached the maximal number of free blocks, the memory would 
> simply be freed. That way both Get() and Save() are O(1).

I already did that before reading your email :)
I implemented it similar, but the freeing is done more agressive.
It doesn't try to maintain a maximum count of free buffers, but
of allocated buffers. We can change that if needed.

Other related posts: