merentha_fluffos_v2/
merentha_fluffos_v2/bin/
merentha_fluffos_v2/fluffos-2.9-ds2.03/
merentha_fluffos_v2/fluffos-2.9-ds2.03/ChangeLog.old/
merentha_fluffos_v2/fluffos-2.9-ds2.03/Win32/
merentha_fluffos_v2/fluffos-2.9-ds2.03/compat/
merentha_fluffos_v2/fluffos-2.9-ds2.03/compat/simuls/
merentha_fluffos_v2/fluffos-2.9-ds2.03/include/
merentha_fluffos_v2/fluffos-2.9-ds2.03/testsuite/
merentha_fluffos_v2/fluffos-2.9-ds2.03/testsuite/clone/
merentha_fluffos_v2/fluffos-2.9-ds2.03/testsuite/command/
merentha_fluffos_v2/fluffos-2.9-ds2.03/testsuite/data/
merentha_fluffos_v2/fluffos-2.9-ds2.03/testsuite/etc/
merentha_fluffos_v2/fluffos-2.9-ds2.03/testsuite/include/
merentha_fluffos_v2/fluffos-2.9-ds2.03/testsuite/inherit/
merentha_fluffos_v2/fluffos-2.9-ds2.03/testsuite/inherit/master/
merentha_fluffos_v2/fluffos-2.9-ds2.03/testsuite/log/
merentha_fluffos_v2/fluffos-2.9-ds2.03/testsuite/single/
merentha_fluffos_v2/fluffos-2.9-ds2.03/testsuite/single/tests/compiler/
merentha_fluffos_v2/fluffos-2.9-ds2.03/testsuite/single/tests/efuns/
merentha_fluffos_v2/fluffos-2.9-ds2.03/testsuite/single/tests/operators/
merentha_fluffos_v2/fluffos-2.9-ds2.03/testsuite/u/
merentha_fluffos_v2/fluffos-2.9-ds2.03/tmp/
merentha_fluffos_v2/fluffos-2.9-ds2.03/windows/
merentha_fluffos_v2/lib/cfg/
merentha_fluffos_v2/lib/cfg/races/
merentha_fluffos_v2/lib/cmds/abilities/
merentha_fluffos_v2/lib/cmds/actions/
merentha_fluffos_v2/lib/cmds/spells/
merentha_fluffos_v2/lib/daemon/include/
merentha_fluffos_v2/lib/daemon/services/
merentha_fluffos_v2/lib/doc/
merentha_fluffos_v2/lib/doc/building/
merentha_fluffos_v2/lib/doc/help/classes/
merentha_fluffos_v2/lib/doc/help/general/
merentha_fluffos_v2/lib/doc/help/races/
merentha_fluffos_v2/lib/doc/help/skills/
merentha_fluffos_v2/lib/doc/help/stats/
merentha_fluffos_v2/lib/doc/man/efuns/
merentha_fluffos_v2/lib/doc/man/lfuns/
merentha_fluffos_v2/lib/doc/news/
merentha_fluffos_v2/lib/doc/old/
merentha_fluffos_v2/lib/doc/old/concepts/
merentha_fluffos_v2/lib/doc/old/lpc/constructs/
merentha_fluffos_v2/lib/doc/old/lpc/types/
merentha_fluffos_v2/lib/domains/ROOMS/
merentha_fluffos_v2/lib/domains/obj/armour/
merentha_fluffos_v2/lib/domains/obj/monsters/
merentha_fluffos_v2/lib/domains/obj/other/
merentha_fluffos_v2/lib/domains/obj/weapons/
merentha_fluffos_v2/lib/realms/petrarch/
merentha_fluffos_v2/lib/save/daemons/
merentha_fluffos_v2/lib/save/rid/
merentha_fluffos_v2/lib/save/users/a/
merentha_fluffos_v2/lib/save/users/p/
merentha_fluffos_v2/lib/save/users/t/
merentha_fluffos_v2/lib/std/login/
merentha_fluffos_v2/lib/std/obj/
merentha_fluffos_v2/win32/
How to make MudOS run as fast as possible on your machine.

1) use appropriate optimization flags for your compiler.  If you are using
gcc 2.3+, then you might want to try the following flags:

-O2 -fomit-frame-pointer -fstrength-reduce

Note that some compilers can produce incorrect code at the higher levels of
optimization.  If the driver behaves inexplicably, trying lowering the
optimization level.  See the Platforms file for more information on
optimization flags for specific platforms.  Also type 'man cc' or ask your
system guru if you are interested in finding out optimization flag information
for your particular compiler.

2) choose an appropriate memory management (malloc) package.  Some systems
have very slow system mallocs (like the HP snake on which malloc used 30%
of the CPU time allocated to the MudOS driver (according to gprof) for one
popular mud).  Both smalloc and bsdmalloc are much more efficient, typically
using less than 1% of the CPU time allocated to the driver.  Note that
smalloc is more space efficient than bsdmalloc (though slightly slower).

3) Try to make your mudlib as memory efficient as possible.  Include
clean_up() functions in your objects whenever reasonable and remember
to use map_delete() to remove elements from mappings when those elements
are no longer needed.  Also take a look at the reclaim_objects() and
reload_object() efuns for saving memory.  Don't use array addition
any more than necessary (especially try not to use it inside a loop
for building arrays).

4) Do _not_ define TRACE_CODE in options.h.  TRACE_CODE can be useful
when debugging code but it slows down most simple LPC instructions (in
eval_instruction()) by a factor of two.

5) Don't give objects heartbeats (set_heart_beat(1)) unless really
necessary.  Do as little in heart_beat() functions as reasonable.
Consider turning off heartbeats when not needed and then restarting
them when again needed.

6) Read the comments in the example config file about hash table size, and
object hash table size--setting proper (large enough) values for these
two hash tables greatly increases overall speed.

7) The opcprof() efun can be used to find out which efunctions are being used
the most.  Rewriting mudlib code that makes extensive use of expensive efuns
can improve performance somewhat.  In order to find out which efuns are
expensive, compile the driver with the profiling flags (-pg if using gcc)
and produce a gmon.out file.  This file can be processed with the gprof
command to find out the percentage of cpu time spent in various different
driver functions.

8) try using the time_expression(expr) function to measure the cpu time used
by various different expressions (time_expression uses the same syntax as
catch()).