Profiling

Doing CPU profiling is actually quite simple; all you have to do is compile with PROFILE_FUNCTIONS turned on, and then use the function_profile() efun. That efun will return the number of times each function in the mudlib is called, the ammount of CPU time spent in the function, and the ammount of CPU time spent in functions called by that function.

Note that these efuns are useless on some systems since the timer isn't accurate enough. However, where it is available, one can write a routine which examines the info and constructs a very accurate picture of how the CPU time is being spent; here is a simple example of how to tally it by object (note: you'll have to rewrite it the old way if you don't have foreach or the new function type):

int total(mapping *info) {
    int ret;
    mapping item;

foreach (item in info) ret += item["self"]; return ret; }

void top_list() { mixed *tmp; int i, j;

tmp = map(objects((: !clonep($1) :)), (: ({ $1, total(function_profile($1)) }) :)); // We could use sort_array() here, but that's an inefficient way // to get the top 10 when there are lots of objects.

for (i = 0; i < 10; i++) { mixed foo;

for (j = i; j < sizeof(tmp); j++) if (tmp[i][1] < tmp[j][1]) { foo = tmp[i]; tmp[i] = tmp[j]; tmp[j] = foo; } printf("%60-O %i\n", tmp[i][0], tmp[i][1]); } }

Similar routines can be written to examine specific functions, etc.

If your concern is memory, look at the mud_status(0) output; that will give you a general idea of where the memory is being used:

Sentences: used by add_action() and call_outs(). Typically, these take up an insignificant amount of space, even on large MUDs.
Objects: The space used by objects and their global variables (although not by the values in those variables)
Arrays and Mappings: The ammount of memory used by allocated arrays and mappings.
Interactives: The space used storing information about users. Should also be quite small.
Strings: The ammount of space used by strings. Note that the which strings are counted by this varies with driver version, so later versions will report more string memory allocated despite the fact that the ammount of memory taken up by strings is actually less; this is due to the fact that one type of strings are not counted in the older drivers.
call out: The space used managing call outs.
Prog blocks: The space used storing program code. If this is unreasonably large, one might want to look at using replace_program().


Tim Hollebeek

Beek @ZorkMUD, Lima Bean, IdeaExchange, TMI-2, and elsewhere