From: Jonas.Maebe@rug.SPAM.ac.ME.be.NOT
In article ,
Glenn Someone wrote:
> One thing that hasn't changed between DOS and Windows is that a disk
> access is still roughly about 300000 times longer than a memory access
> and a multi-tasking system doesn't change that fact. Blantantly put,
> the more real memory I can get, the less disk access that must be
> done. The less memory I get, the more disk access that happens. And
> even worse, if that memory I think I get is really swap space on disk,
> it turns into even MORE of a performance nightmare like I mentioned
> because I might be writing it to disk multiple times.
Indeed, so the best strategy is to let the OS handle this and find the
right balance. On *nix-type systems, you do this using memory mapped
files: you more or less say that the "swap" space corresponding to a
particular memory range lies inside an already existing file.
Therefore, if you read from that address, it will "swap in" part from
that file. If you do not modify the data, it does not have to be swapped
out later when more memory is needed elsewhere.
You can of course use plain read/write semantics (also under Dos, I
don't know whether dpmi knows memory mapped files), and in this case the
OS will cache as much data as possible. You are trying to implement a
disk cache on top of a disk cache, thus double buffering the data and
wasting memory.
Additionally, it's much harder for you or a user to figure out how big
this disk cache can be in order for optimal global performance, as you
have a very limited view of the system. Therefore, just leave the the
bulk of the caching to the OS and use a small internal buffer (since
even if the data comes from the cache, it's still a system call/context
switch you have to go through).
Jonas
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
