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.
> >True, they can be compressed, but they will still take about the same
> >amount of raw space as a binary file -- plus there is the inode/sector
> >size issue, as well as inode usage.
>
> No, a non-stock MUD binary pfile with about 136 players takes up 250k. You
> lose heavily with the static array of strings. That comes out to about
> 1.8k per player with binary. An ASCII pfile would have to be 22 lines long
> and fill up all 80 columns of every line to be 1.8k.
>
> 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
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.
> >And with pfiles scattered across the disk of the server, it can make
> >random access to them rather slow. There is much less overhead involved
> >in a flat binary file than having hundreds or thousands of ascii files
> >floating all over the place.
>
> Linux (2.1, still using as example) has a directory cache which would
> handle that with ease. Besides, that is what all file systems are
> optimized for, fast operation under all circumstances.
Not true at all. Not all file systems are optimized for speed.
ext2fs might be, but your definition of speed might be different from
mine. In a multiuser environment, fast, fair file access isn't
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.
> >But there is the issue of parsing the entire thing, and then rewriting
> >it, when a player attempts to log in. Or when they login with a bad
> >password. Or any number of other things -- parsing the entire file
> >could be painfully slow.
>
> 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.
> 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.
> 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.
> >Also we lose the capability to, say, find out just how much gold is in the
> >players' posession. Maybe not a huge loss, but it is useful information
> >for an economy. It makes finding info and statistics on players rather
> >difficult. Again, maybe not something commonly done, but it is a useful
> >option.
>
> No, we would not.
>
> 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.
> 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.
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.
That's not to preclude the possibility of a semiofficial patch. If
the current save/restore code is sufficiently modularized, then there
can be all kinds of interfaces; ascii, binary, flat file ascii,
mixture, etc. Simply define a set of functions that the mud needs to
save and restore players, and abstract away the actual storage
mechanism.
The current code is somewhat close to that... but not quite enough to
make new systems plugable.
--
James Turner turnerjh@xtn.net
http://www.vuse.vanderbilt.edu/~turnerj1/
+------------------------------------------------------------+
| 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