Re: [Circle] [CODE] Search buffering

From: Sammy (
Date: 08/25/96

On Fri, 23 Aug 1996, Katzlberger Thomas wrote:

> I doubt that this will increase performance a lot.
> Binary search (as used here) takes about 20 acesses on max.
> 64000 32000 16000 8000 4000 2000 1000 500 250 125 62 32 16 8 4 2 1
> You don't save a lot in this case with your improvement.
> The zonereset lag may be caused by virtual memory pageing of your 
> host (this is more likely). The only solution for this is to
> upgrade the host you run on with some simms. 

There's no problem with memory.  The server's got more than enough.  The 
problem is that it's an old sparc 10 running doing all the durties of an 
ISP.  It's so slow I can check the load averages and tell you how long a 
reboot will take (anywhere from 5 to 15 minutes depending up the number 
of people using the system).  Since I've got nothing better to do while 
the mud boots I watch the syslof sometimes, and noticed that there's a 
certain zone that loads about 100 mobs of 7 or 8 different types that 
sometimes took 2 minutes to reset.  I added the zone buffering and sorted 
the reset file to put all similar mobs together and now the reset is much 

If those mobs took 10 tries to find, and now they take 1, that's a nice 
improvement for me.  You'd be amazed at some of the strange optimizations 
I'm putting in to get a mud to run on this beast :)

| Ensure that you have read the CircleMUD Mailing List FAQ: |
|   |

From Sun, 25 Aug 96 13:51:04 +0200
X-SystemInfo: MyE-Mail: EMail
X-Message-No: 4045 (database)
From: jeremy elson <>
To: Daniel W. Burke <>
Subject: Re: [Circle] Helpful Tip 
Date: Sun, 25 Aug 96 12:51:00
Message-ID: <>
X-POP3-Rcpt: lk4150@per
Return-Path: <>
Received: from QUCDN.QueensU.CA (QUCDN.QueensU.CA []) by (8.6.12/8.6.12) with SMTP id NAA23187 for <>; Sun, 25 Aug 1996 13:39:19 +0200
Received: from by QUCDN.QueensU.CA (IBM VM SMTP V2R2) with TCP;Sun, 25 Aug 96 07:44:36 EDT
Received: by (SMI-8.6/SMI-SVR4)id GAA08881; Sun, 25 Aug 1996 06:59:29 -0500
Received: from by (SMI-8.6/SMI-SVR4)
Received: by (AIX 3.2/UCB 5.64/4.03)
Precedence: bulk

>> This applies to linux/unix coders specifically.
>> This is a real easy way to 'save your ass' when you
>> completely jack up your code.
>> Here is what I do:
>> 3) I create another directory called '.source.backup1' and 

> This is pretty close to something that I finally decided to use...
> I've started keeping a  CHANGES file up to date, and I constants keep a 
> ZIP file in the base directory of the mud (where configure/autorun etc 
> is run from) containing the source and makefile, and have a script that 
> copies the ZIP it a backupdir with a specified name that's usually 
> todays 
> date, and it copies the CHANGES file from the /src dir along with it 
> making the name <date>.CHANGES so I know what's in that file... been a 
> great system, and has already saved my ass more then once :)

I just discovered an even better tool: RCS (the Revision Control 
System).  I started using it for the software I'm writing at work.  You 
can get it free from GNU (

RCS is ideally suited for MUD coding for 2 reasons: First, it very
efficiently (i.e., without using a lot of disk space) saves every revision
of the source code you submit to it (by using diffs).  So, if you start
experiencing some untraceable bug, you can keep backing out your changes
one revision at a time until you find a revision that works correctly.
Then, use RCS's diff command to show you all the changes between the 
revision that works and your current revision.

The second reason it's perfect for MUD coding is because it "locks" 
pieces of the source code while you're working on it to prevent more than 
one coder from working on the same file at the same time.  You can check 
out the various source files either read-only or read-write, and only one 
person can have the source checked out read-write at a time.  The idea is 
that each coder can work in his own home directory, with an entire copy 
of the source code but only a small piece of it writable.  Then once the 
piece you're working on it stable, you check it back in and it becomes 
integrated with the source.

It has lots of other neat features that are explained in the docs: for 
example, by making a small modification to the header files of Circle, it 
will imprint the binary itself with a revision number for each source 
file.  That way, if you're having bugs with a binary file, you can use 
"strings" and it will tell you exactly which revision numbers of source 
created the binary (i.e. act.informative.c v1.23, act.wizard.c. v1.44, 
act.other.c v.1.12, etc.).  Then you simply tell RCS to retrieve those 
revision numbers of the source code, and -- voila!  You have a snapshot 
of the source code that created the binary in question.

Another nice feature: every time you submit a new revision of a source 
file, it asks you for a ChangeLog entry where you can type a description 
of what changes you've made to the source.  Then, when the source is 
checked out, it automatically constructs a comment at the top of the file 
with the ChangeLog, like this:

 * EVE dispatcher
 * J. Elson, started 14 June 1996
 * $Id: 0615.html,v 1.1 2000/12/19 13:53:02 furry Exp $
 * $Log: 0615.html,v $
 * Revision 1.1  2000/12/19 13:53:02  furry
 * *** empty log message ***
 * Revision 1.3  2000/12/08 04:19:27  furry
 * *** empty log message ***
 * Revision 1.7  1996/07/03 00:03:35  jelson
 * Changed enter_zoom_mode(): when there is no selection given (e.g. the
 * zoom button on the panel has been pushed), and there has been no prior
 * selection, select the 4th slice instead of the 1st slice so that the left
 * screen doesn't have to update.
 * Try to move the left stack more intelligently so that the >> and << buttons
 * have meaning in ZOOM mode.
 * Added IMAGE event handling for viewbox events to handle double-clicks.
 * Changed panel registration to only happen when we're not in the rcws1
 * or rcws2 debugging modes.
 * Revision 1.6  1996/07/01 21:14:07  jelson
 * IMPORTANT: The dispatcher no longer executes its own locally dispatched
 * STATE events.  It now only relays them to the server, and the server has
 * been changed to echo STATE messages back to all clients including the
 * sender.  This prevents race conditions which can lead to unsyncronized
 * displays since the server is single-threaded and will serialize all
 * STATE events.
 * Most of the initial code for ZOOM mode has been written; operation of the
 * panel now depends on the state of zoom mode (left and right can either
 * mean "back one row" or "back one slice").
 * stack_move() changed so that the left viewbox is always full.

...etc.  (I've cut out the next 200 lines of comments for the sake of 
brevity but this should give you the idea :-))

The only disadvantage of RCS is that it can be hard to use before you're 
used to it.  But it's worth it!

| Ensure that you have read the CircleMUD Mailing List FAQ: |
|   |

This archive was generated by hypermail 2b30 : 12/07/00 PST