|
Yes if you are on a PowerMac.
Otherwise, only if you need it.
Though RAM Charger "dynamic" memory is valauble no matter
how much memory you have, the recent drop in RAM prices
makes it very rare that users need to use virtual
memory. As one RAM Charger user user wrote on our public
beta list:
"Nowadays, the *need* for [increasing memory with virtual
memory techniques] is greatly reduced. Ram is cheap! Dynamic
allocation of memory is what is needed..." - Charles Bouldin
So, why would anyone want to use Apple Virtual Memory or
RAM Doubler virtual memory?
Our opinion is that if you run any native applications
you should run with virtual memory on to take
advantage of File Mapping - with the LEAST amount of
virtual memory you can specify. Since File Mapping is
not functional under non-PowerMac systems, 68K users need
not run VM unless they cannot run the programs they require
with VM disabled. Because RAM Charger helps users distribute
their memory more efficiently, with VM on or off, users may
find that they can accomplish their objectives without
enabling VM.
What is File Mapping?
File Mapping is an aspect of virtual memory
wherein an application's code does not have to be loaded
from your hard disk into RAM until it is required. Virutal
memory must be enabled for File Mapping to be
active, and connot be disabled when virtual memory is
on, though no specific amount of virtual memory is
required.
Using the File Mapping aspect of VM, Mac OS
pretends that the entire applicaiton is in memory at
application startup - by "mapping the file into memory".
Then, when parts of the application are required to perform
opertations (from drawing windows to spell checking to
saving files) they are loaded from the disk as needed using
traditional VM interupt
techniques. Should RAM become full, the parts of the
program not in use may be discarded - and must only be
loaded again from the hard disk if it is used again.
Traditional Mac applications accomplish similar
objectives using "segmenting", where the author breaks up
the application into chunks which can be loaded and unloaded
when required. However, the older technique requires special
programming of the application, and limits the "chunks" to
predefined sizes (which usually end up being relatively
large). File Mapping is completely transparent to programs,
requiring only that they have a "Code Fragment" in their
"data fork" which is the common way Native applications are
built, and load/unload will be done in relatively small
"page" sizes.
Why use virtual under Power Mac?
As far as we know, File Mapping is only supported under
Power Mac, and only when VM is enabled.
If you do not enable VM (and thus File Mapping) then the
ENTIRE code of a NATIVE application will be loaded into RAM
(because it is not segmented) when you start up the
application - taking more time and RAM. If you are using
Virtual Memory then Mac OS will only load the parts of the
CODE into RAM that are actually being used (when they are
needed). Obviously, VM's File Mapping may result in much
more efficient use of your RAM and may speed up operation.
If you are not running any native applications then there is
no benefit to using Virtual Memory (unless you really need
it).
Since Ram Doubler is an improved form of virtual memory,
we recommend considering it. However, we cannot say how much
better it is than the current PowerMac implementations,
which may be very good, and thus what its financial "value"
is.
Why the least amount of VM possible?
Use the least amount of VM possible to avoid
inadvertantly using more memory than your physical RAM,
which can cause slowdowns. This is especially the case when
using RAM Charger since you will be able to pack the memory
much more efficiently, stressing the VM system. Though using
RAM Charger with VM will provide more flexibility, just like File
Mapping adds more flexibility to standard VM, it will also
make it easier to fill the VM and stress the system.
Since you must enable VM in order to activate File
Mapping, and since filling more VM than you have real
RAM can cause slowdown, and since File Mapping actually
fills VM beyond the size of VM you set, we recommend setting
the VM amount as low as required for your usage.
However, if you are not limited by disk space usage, and
you keep in mind the possible impact from actively "using"
too much of your vitual memory, there is no reason you
cannot set VM as high as you like - giving you the most
operational freedom. Just don't forget that this is the
reason should you stress your memory and experience strange
pauses and jerky operation. That is...don't blame it on me!
Why the special File Mapping name, isn't this
just standard VM?
File mapping is simply an optimized aspect of VM. By
tracking the "File Mapped" virtual memory code seperately,
the VM system is able to recognize that when mapped code
must be "paged out" (to make room in RAM for other data) it
can be discarded, since it is already on the hard disk,
instead of being slowly written to disk. Thus the "File
Mapped" designation on some of your virtual memory speeds up
operation. Giving it a cool name adds a nice buzz word for
the industry. In other operating systems File Mapping is
just considered part of the VM system, without any such
fancy designation (as far as I know).
How much of my specific application is "File
Mapped"?
If you do a "Get Info" on an application that has any
"File Mappable" code, then the size of the "File Mappable"
code is shown at the bottom of the Get Info window (it will
say "Note: memory requirements will increase/decrease...").
This "adjustment" simply shows the size of the File Mappable
code "fragment", which is stored in the data fork of the
file. As far as we know, the system does not have the
ability to File Map fragments in resources (speculation).
If you start with VM off then the "File Mapped" amount of
memory (RAM since vm is off) will be required and used
immediately on startup. If VM is on, then the "File Mapped"
amount of code will be reserved in virtual memory beyond
your total memory, but real RAM will not be used except for
parts of the File Mapped code as they are actually used.
How much RAM is in use (the secret)?
(Or... how close am I to slowing down since RAM is full
and VM will have to work hard now?)
Of special note is that the File Mapped CODE will be
loaded OUTSIDE your traditional Total Memory space shown in
about this mac, and thus you have no control over how much
VM is allotted for CODE.
The bottom line is that if you are running native
applications under Power Macintosh with VM enabled, native
application CODE will be "mapped" OUTSIDE the virtual memory
shown as Total Memory in your about this macintosh. As a
result, be aware that if you are using Virtual Memory under
Power Mac you may in fact be using WAY more virtual memory
(because the native application code that has been used is
mapped OUTSIDE the traditional memory space) and so you may
see serious slow down.
For example:
About This Mac may show you are only using 12 of 17 megs
VM on a 16 megs RAM machine, with Vm turned its lowest.
However if you are running Excel you will have 10 megs
file mapped (for a 27 megs total VM in reality) which may
have 4 megs loaded in RAM because of the parts of the
Excel applicaiton you have used were (for a total of 16
megs in use). In this case, your RAM is full despite the
"12 megs" shown to be in use in About This Mac. You may
start to see slowdown.
This is only important in understanding why your mac may
appear to slow down apparently prematurely when using
virtual memory.
So, then, how do you know how much Virtual Memory you are
actually have at any given time? You would have to add up
all the File Mapped code sizes listed at the bottom of the
Get Info window for each running application, and add this
to your total memory.
So, then, how do you know how much RAM you are actually
using at any given time, and thus how close you are to
stressing VM? You would have to determine how much of the
File Mapped code is actually in RAM (which you can't) and
add this to the memory shown to be in use. Thus, you can't
figure it out. Good luck. Just don't push too hard and you
may not slow down.
| 
