[Management of "used" and "free" areas of NEWS.DAT]
> In simple terms, there are several obvious options. Best fit ---
> choose the smallest hole that fits the article. Worst fit --- choose
> the largest hole (and of course, the unused portion of the hole becomes
> a new hole; this also applies to best fit). First fit --- choose the
> first one you encounter in scanning the space, as Yngvar has described.
> Random --- pick one from random.
>
> It turns out that results are a bit counter-intuitive. I was taught
> that someone did some experiments, and the result, best fit is the most
> inefficient, worst fit is somewhat the best.
I've heard about something similar. The reason, apparently, was that
using "best fit" usually resulted in every allocated block being
followed by some free space, too small to be useful for anything.
Anyway, this assumes disk or memory space, in which it doesn't matter
what part is being used. I would *not* use "worst fit" for NEWS.DAT,
because the largest free area is of course the area *following* the last
article in the file, which can be as large as all the remaining disk
space. Then NEWS.DAT would just grow and grow until it filled the
entire disk.
For NEWS.DAT, I think it would be important to select an algorithm in
which the used area naturally migrated toward the beginning of the file.
First fit is the only one of these that fits (pun unintended), and it's
also a generally efficient algorithm. Maybe there is another algorithm
that would work even better, but neither best fit nor worst fit would
work at all.
If first fit *is* used, of course I'm satisfied. I'm just a bit
suspicious about how slowly NEWS.DAT shrinks. I don't like EXPIRE -r,
because when reading a followup I frequently find myself wanting to read
the original message. I see that as some of the *purpose* of using a
database reader like Yarn rather than a packet reader. And of course it
wrecks the message tree that Chin made for version 0.91.
Yngvar