A message from a member of the ASOFT forum, sorry I forgot the name.
Ingo
------------------------------------------------------------------------------
If you use the -dem switch, then the .EXE is demand paged loaded from the disk
at start up.  This means that more and more of 3DS will be sucked into memory
as you use various portions of the program.  My tests show about 60% of the
3DS code is loaded at startup, so using the -dem switch may help reduce 
load times a little.

Now, the rest depends on other switches.  If you are over a net and 3DS is on
the server, you SHOULD NOT use the -dem switch, but should use the -nopgexp 
switch.  This causes all of 3DS code to be read into memory, and then written
to the swap file if it needs to be paged out (which better be on the local 
drive by using the -swapdir switch!)

If running locally, there is no reason to use the -nopgexp switch unless you 
have a faster drive for swaping.

If 3DS needs to swap out code, unless the -nopgexp switch is used, the code 
is NOT written to the swap file.  It is simple marked as missing.  When it is
later needed, it is simply read from the .EXE file again.

I recommand using the -nur switch along with the -noswfg switches.  
The -noswfg helps keeps the swap file smaller but may cause some swapping
operations to take a little longer.  Fast harddisk and a small diskcache 
will basically remove the overhead.  The -nurswitch tends to give a better
use of memory when heavy swapping occurs.

If you are swapping extensivly, reducing the -vscan value will help the VMM 
make a better decision.  Try -vscan 10000 or -vscan 8000.

A little known trick is to set the environment variable DOSX  to one or more
of these values, much faster than reconfiguring each time.  For example:

SET DOSX=-vscan 8000 -nur -noswfg -nopgexp -swapdir c:\swap

The DOSX environment variable overrides any Phar Lap setting in the software 
set by cfig386.

