Re: Better string swapping.

From: George (greerga@CIRCLEMUD.ORG)
Date: 07/04/98


Here's a reply from me from a reply from Erwin, with his permission.

Short version: It's a working but less than perfect example which could
really use an index system to reduce the number of seeks.

See his other mail I'll forward for all of the examples.

---------- Forwarded message ----------
Date: Sat, 4 Jul 1998 16:11:50 -0400 (EDT)
From: George <greerga@circlemud.org>
To: "Erwin S. Andreasen" <erwin@andreasen.com>
Subject: Re:  Better string swapping.

On Sat, 4 Jul 1998, Erwin S. Andreasen wrote:

>I understant you meant this as only an example, but it really breaks my
>heart to see this:

Yup, it's a quick hack.  Doing nothing but 10,000 'looks' in room 18647,
the highest I went to in stock CircleMUD showed:

  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 77.54     10.46    10.46    20006     0.52     0.52  find_room
  6.67     11.36     0.90                             mcount
  1.70     11.59     0.23    10004     0.02     1.15  command_interpreter
  1.70     11.82     0.23        1   230.00 12279.80  game_loop
  1.11     11.97     0.15   100062     0.00     0.00  write_to_output
  1.04     12.11     0.14    10003     0.01     1.10  look_at_room
  0.96     12.24     0.13      101     1.29     2.58  mobile_activity
  0.82     12.35     0.11    10010     0.01     0.01  write_to_descriptor
  0.82     12.46     0.11    10003     0.01     0.01  do_auto_exits
  0.74     12.56     0.10    14937     0.01     0.01  special
  0.44     12.62     0.06    10003     0.01     0.01  sprintbit
  0.37     12.67     0.05    19644     0.00     0.00  fread_string
  0.30     12.71     0.04    56824     0.00     0.00  circle_random
  0.30     12.75     0.04    10010     0.00     0.02  process_output
  0.30     12.79     0.04    10003     0.00     0.53  get_room_name

This is a bit contrived because no one does 10,000 looks in a Tintin++
loop at the highest room.  My ruling on the function was that it was "good
enough" without further complicating matters.  Now, if I actually used the
function and it wasn't just a (working) example...well, see below.

>If the file was 400k as you say, then this means 100 * 4096 buffers - thus
>this will result in at least 1200 system calls if you want the last room!
>(400 reads, and 800 seeks - I think fseek() always causes a lseek()).

Not always, it defers it until the next read/write.  In this case, it
effectively does though since the seek is followed by a read.

>That is really inefficient. So, consider making an *index* file at the
>same time: before writing to the main data file, write the current
>position to the index file.

Guilty as charged.  I would do something like the above personally. I'd
recommend anyone seriously in need of this sort of thing to consider your
suggestions for improvement.

The fact I put it on the FTP site instead of my own page is sort of an act
of "disowning" any relation to the actual code itself. :)

I think of it as a huge memory/processor tradeoff for those people who are
limited by memory but don't use much processor time anyway. Myself not
included in the above category, I don't have an impetus to make it perfect,
just usable.

Also requires less changes than the unload/reload method..

[ And if you don't mind, I'd like to post this reply to the mailing list so
people interested in this sort of method will know better ways to do it. ]

--
George Greer, greerga@circlemud.org | Genius may have its limitations, but
http://patches.van.ml.org/          | stupidity is not thus handicapped.
http://www.van.ml.org/CircleMUD/    |                  -- Elbert Hubbard


     +------------------------------------------------------------+
     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
     +------------------------------------------------------------+



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