## 6.1 What is grep? Is it useful?

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.

## 6.2 What about Perl?

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.

## 6.3 What is profiling?

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.

## 6.4 How do I profile my mud?

1. Add '-pg' to the PROF line in your Makefile
2. Do a clean recompile.. ie delete all .o files and do 'make'
3. Reboot your mud
4. Let the mud run for a while, a day or two at least, then shutdown..it's important you shutdown, the mud needs to exit cleanly
5. Go into your area directory and type 'gprof'
6. Peruse the information

## 6.5 What can I do with the profile information?

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.

Main Rom Page Index 1 2 3 4 5 6 7 8