If you're starting your MUX from scratch, all you need to do is specify in
the Makefile whether you want to be disk based or memory based, and compile,
following the instructions for creating a database. Converting from disk
based to memory based, and vice versa, is a bit more difficult.

Converting from memory based to disk based:
------------------------------------------

It is simple to convert your database to a disk based format, as
follows: recompile with the the disk based options set in the Makefile.
start up the game, log in as a wizard, and shut it down.

Converting from disk based to memory based:
------------------------------------------

You need to use db_unload to convert your gdbm database to a flatfile, as
follows:

	db_unload <gamename>.gdbm <gamename>.db.new <gamename>.db.FLAT

You then need to remove <gamename>.db.new, <gamename>.db,
<gamename>.gdbm.db, and <gamename>.gdbm. When that is done, rename
<gamename>.db.FLAT to <gamename>.db.new. Start up the game.


A comparison of disk based and memory based database storage methods.
--------------------------------------------------------------------

1. Memory based:

- Advantages:
 	- Eliminates the overhead of caching, and accessing the disk to
	  read and write data.
	- Total database usage on disk is usually smaller that a disk-based
	  setup.
	- A memory based setup dumps and loads using a flatfile, which is
	  easier to manage and easily compressible when dumped by the MUX.
- Disadvantages:
	- Memory usage grows as the size of the database grows.

2. Disk based:

- Advantages:
	- Uses a fixed amount of memory independent of database size.
	- Faster database saves.
- Disadvantages:
	- Slower performance due to the overhead of caching, and getting
	  bits of data to/from disk.
	- Uses 3 files for the database, and usually takes up more disk
	  space than a memory based system, and the main text database is
	  not compressible at dump time.

Memory based usage is preferred _if_ you have enough memory to support a
growing database, however, when memory is at a premium and memory usage is
the key point of whether you remain on your site or not, disk based usage is
the way to go.

Saving disk space:
-----------------

- If you are using a disk based setup, consider converting to a memory based
  setup, which is much more efficient with disk space.
- Enabling the config parameter 'compression', and specifying a
  'compress_program' and 'uncompress_program' will save disk space under
  memory based usage and disk based usage, but it makes much more of a
  difference with memory based because it compresses the entire database.
- Enabling radix compression (see README.COMPRESSION) will reduce the size
  of a disk based database AND its memory usage. On a memory based setup, it
  will only reduce memory usage.

Saving memory:
-------------

- If you are using a memory based setup, consider converting to disk based.
- On a disk based setup, reduce the size of the cache, preferrably making it
  narrower (see README for tips on the cache)
- On both disk and memory based setups, enable radix compression (see
  README.COMPRESSION)
- Adjust HASH_FACTOR in config.h: 2 is recommended, altho 1 is usable and
  results in less memory usage.
- Adjust OUTPUT_BLOCK_SIZE in config.h: this should be a power of 2,
  preferably in the ranger of 4096 to 16384. Any value over the config
  parameter 'output_limit' is wasted.


You should juggle these options until you find a setup that works, and gives
you the best performance. There is no 'right' way to set up a MUX, it always
depends on the capabilities of the system you are running on, and how much
of those capabilities you can use.

Memory debugging:
----------------

If you turn on malloc debugging in the Makefile (-DMCHECK) you have a wide
range of information to use in hunting down memory leaks or corruption.
@stats/all displays statistics on memory usage. This is useful to check
before and after executing a command to see if it leaks memory (altho you
need to do it multiple times to make sure it's really leaking).

It also enables memory tracing, where all allocation information is written
to a file called mtrace.out in the game directory. The awk script mtrace.awk
is included and analyzes mtrace.out for potential problems.