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 better. 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 :) Sam +-----------------------------------------------------------+ | Ensure that you have read the CircleMUD Mailing List FAQ: | | http://cspo.queensu.ca/~fletcher/Circle/list_faq.html | +-----------------------------------------------------------+ From osjelson@spinach.mscc.huji.ac.il Sun, 25 Aug 96 13:51:04 +0200 X-SystemInfo: MyE-Mail: EMail X-Message-No: 4045 (database) From: jeremy elson <osjelson@spinach.mscc.huji.ac.il> To: Daniel W. Burke <dwb@ix.netcom.com> Subject: Re: [Circle] Helpful Tip Date: Sun, 25 Aug 96 12:51:00 Message-ID: <9608251051.AA125130@spinach.mscc.huji.ac.il> X-POP3-Rcpt: lk4150@per Return-Path: <@QUCDN.QueensU.CA:owner-circle@cspo.queensu.ca> Received: from QUCDN.QueensU.CA (QUCDN.QueensU.CA [130.15.126.2]) by per.cybercity.dk (8.6.12/8.6.12) with SMTP id NAA23187 for <lk4150@krull.dk>; Sun, 25 Aug 1996 13:39:19 +0200 Received: from cspo.queensu.ca by QUCDN.QueensU.CA (IBM VM SMTP V2R2) with TCP;Sun, 25 Aug 96 07:44:36 EDT Received: by cspo.queensu.ca (SMI-8.6/SMI-SVR4)id GAA08881; Sun, 25 Aug 1996 06:59:29 -0500 Received: from spinach.mscc.huji.ac.il by cspo.queensu.ca (SMI-8.6/SMI-SVR4) Received: by spinach.mscc.huji.ac.il (AIX 3.2/UCB 5.64/4.03) Cc: circle@cspo.queensu.ca, osjelson@spinach.mscc.huji.ac.il Sender: owner-circle@cspo.queensu.ca 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 (ftp.gnu.ai.mit.edu:/pub/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! Jeremy +-----------------------------------------------------------+ | Ensure that you have read the CircleMUD Mailing List FAQ: | | http://cspo.queensu.ca/~fletcher/Circle/list_faq.html | +-----------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/07/00 PST