On Tue, 21 Apr 1998, James Turner wrote:
>> ASCII can be compressed when not in use also. (Can increase speed too if
>> you have slow hard drive and fast processor.)
>
>Is this really the case?
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.
>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.
(*) - I'm not, my server:
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda2 911226 631005 233148 73% /
/dev/hdc1 2028819 1260937 767882 62% /home
Filesystem Inodes IUsed IFree %IUsed Mounted on
/dev/hda2 235520 24048 211472 10% /
/dev/hdc1 258048 17988 240060 7% /home
73% block space used and still 90% inodes are free. This is with a 4k
block size, you'd have even more free inodes with 1k.
>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.
>Of course, in the current code, there is still a need for random
>access of the drive to find the object files.
Correct.
>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.
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?
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."
real 0m0.871s
user 0m0.750s
sys 0m0.120s
>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.
>If the desire is ease of modification of the database entries, then
>perhaps some form of editor could be made. A text-based one (not
>even ncurses, just prompt driven) could go a long way.
You can use emacs, cat, or pico with ASCII pfiles in addition to on-line
versions such as set or a player editor.
>Do you mean supporting both?
Yes, we would support both.
--
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