In the equally as immortal words, "grep is your friend too". The standard
Rom distribution is 45,000 lines of code, and grep is the most widespread
utility to do searches on all the files. Typing "man grep" on a unix box
is a good start, as it can do some quite nifty things. But for starters,
: grep MAX_LEVEL *.h - find which header files MAX_LEVEL is defined/used
in.. case sensitive
grep -i do_tell *.c - find which source file has the do_tel function..
case insensitive due to the -I switch
grep -c class merc.h - Count the number of times the string 'class'
appears in merc.h.. case sensitive due to no 'i' switch
plus many more.. read the manual.
Perl is probably of limited use in the overall scheme of running a mud, but can provide quite useful administration facilities. It is far from infrequent to see people with perl scripts to do various things with player files, such as cleaning out the directory of unwanted files and such. Other similar utility applications have had perl scripts used for them. The advantage of perl is that it allows you to write a quick script that can do quite sophisticated processing, but it is perhaps not suited to much larger uses.
Perl is especially suited for text manipulation. For example, to replace
the string "armor" with "armour" in several files, you need but to do
this:
perl -pi~ -e 's/armor/armour/g' file1 file2 file3
This edits the three files in place, leaving a backup in file1~, file2~
etc.
One of the concerns a mud administrator rightly has is the amount of computer resources the mud is hogging. Maybe the machine hosting the mud is low spec, maybe it's a site where resources are limited by policy, or maybe it's just the admin being conscientious. As mentioned in an earlier section, Rom has ram, hard disk and cpu considerations. Disk space usually isn't a problem since it's so cheap for massive storage nowadays, ram is considered to be hard to optomise since it's usage comes mainly from areas, so a frequent favourite choice for efficiency is the cpu usage. There is a technique known as profiling, by which you recompile the mud with certain switches added, let it run for a while and after shutting it down you get a file showing how much of the cpu time was taken up by every function in the mud.
To be blunt, not much. Many people get the idea that they can greatly increase the efficiency of the code, then find out the hard way that speeding up most functions in the code by a *significant* amount is far from an easy task. What profiling can do is show you just how your mud is using it's time, and perhaps by this you'll see some function that shouldn't be a hog using an inordinate amount of cpu time. What you probably will find is that the *_update() functions use the majority of the cpu time, and these are already quite well optomised. Note that if you try to profile the mud and only let it run for a short time, you will see the functions used a lot during bootup (such as fread_string and such) using much more of the resources than they actually do once the mud is up and on it's feet.