On Wed, 22 Apr 1998, James Turner wrote:
>George <greerga@CIRCLEMUD.ORG> writes:
>
>> The increased speed by compression is a proven fact, if you use the correct
>> routines. If you use a lightweight decompression routine with a fast
>> processor you do not have to read as much from the slower hard drive. By
>> reducing the read time from the hard drive and having fast decompression,
>> it speeds things up.
>
>Reading 4k from a disk won't really get the speed boost you're talking
>about -- in a case like this, the overhead of seeking the position on
>the drive will far outweigh the decompression time. It won't speed
>things up unless these files are huge.
I didn't say it would speed it up dramatically (especially if using SCSI
drives where you may slow down), but you would still save disk space while
you're not using the player.
>> An inode is typically 4k (using Linux as an example) although it may be as
>> low as 1k. If you're worried about inodes(*), then you can put all of the
>> ASCII pfiles in the same file.
>
>bzero(st, sizeof(*st));
>
>before storing each character. The static string arrays will be
>filled with zeroes, which any compression program can make quite
You cannot compress a binary pfile since everyone uses it. That is, unless
you split the binary file up per player, which would lose all advantages of
being binary in the first place.
>small. Further, it would be possible to have one large string buffer,
>and reference strings via index and length. The remainder of the
>buffer could be zeroed out, resulting in even more space saved, at the
>cost of some trivial string handling at save/restore time.
But you cannot compress the binary file while the MUD is running. You can
with ASCII since it is per player.
>measured strictly in throughput. A directory cache is nice, but it
>won't eliminate the overhead... overhead simply not present in the
>flat type of file we have at present.
Sure it is, your 'flat' file may be fragmented all over the disk from
beginning to end.
>> All players would have their own file so you do not have to rewrite every
>> file. Putting all players together (which you could do if you're worried
>> about inodes, see above) would not be a good idea because then you could
>> not manually edit players without possibly overwriting data written in the
>> mean time.
>
>Putting all players in a single file would be quite dangerous. One
>parse error, one bad entry, and everyone after that person could be
>lost. Not an issue with the current system.
I said that, "Putting all players together would not be a good idea..." and
then gave an example. I mentioned you could if you were worried about
inodes, but I have no intention of it.
>> And you'd only have to open the players file and scan for the 'Password:'
>> tag. You wouldn't have to parse the whole file yet. I think it would be a
>> good idea to parse the whole file though, the db.c routines read the entire
>> world in very little time, why would ASCII pfiles be different?
>
>Again, in a multiuser environment, or on a server with multiple muds,
>this is adding quite a bit of overhead. Particularly the highly
>non-localized disk access. Hard drives are the real bottleneck.
You're scanning through a 3k file on a system that can do many megabytes of
transfers per second. Servers with multiple MUDs have lots of RAM free for
cache. (If they don't, the administrator has a big problem.)
>> It takes about 9/10 of a second for CircleMUD (stock) to read and parse the
>> entire world on my Pentium 233 MMX. I don't see opening one player and
>> parsing them (or even the entire pfile) as "painfully slow."
>
>Compared to reading a binary file, the parsing will be orders of
>magnitude slower.
I said you can parse the entire CircleMUD world in 9/10 of a second. Your
average player file will be about 3k. The CircleMUD _rooms_ (nothing else)
total 1.5 megabytes. The entire world is 2.5 megabytes. 9/10 of a second.
Player files are 3k (overestimation). Your computer wouldn't even blink to
parse that. Please stop arguing for the sake of arguing. The speed factor
here is moot.
>> The interfaces can remain exactly the same as current. What you can do
>> now, you could do with ASCII pfiles also.
>
>Not true. Count the number of players. Find out how much gold is in
>each player's posession then add the total. List all imms. List all
>people from the same site.
>
>With ascii pfiles, that involves opening, scanning, and closing each
>file. That is quite a bit of overhead. Several orders of magnitude
>slower than can be done with the current system. Prohibitively slow
>on a multiuser system.
I said 'The interfaces can remain exactly as current.' In order to total
how much gold is in each players posession you could _still_ have to call
load_char() on each one if I kept the interface the same. If you had looked
at the current code to scan through the pfile you would see that there
could be no difference in execution. And as I said, the speed issue is
moot.
>> You can use emacs, cat, or pico with ASCII pfiles in addition to on-line
>> versions such as set or a player editor.
>
>Not for a binary database. There is no question of ease of off-line
>maintenance in an ascii pfile situation. But in a binary system, that
>ease is given up in favor speed and other niceties. I'm not totally
>convinced ascii pfiles are worth the transition, particularly if both
>are supported.
Speed is moot, I can parse 2.5 megabytes in 5 directories and multiple
files in 9/10 of a second. 3k of a player file will not matter.
>Again, patches will have to support both. There will be the added
>burden of maintaining both, also. One or the other should be picked
>as the standard method.
If the interface is the same, there will be no difference to patches unless
they deal directly with the store_to_char/char_to_store type routines.
>The current code is somewhat close to that... but not quite enough to
>make new systems plugable.
Well, I have an idea on how to do it, and it won't be hard.
--
George Greer - Me@Null.net | Genius may have its limitations, but stupidity
http://www.van.ml.org/~greerga | is not thus handicapped. -- 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