On Wed, 22 Apr 1998, James Turner wrote:
>Compressed storage could easily be added to the current binary
>system. Two options -- make a second file, players.cryo, where
>entries are copied during a playerpurge, or write the char_file_u to a
>separate file for players who are offline. Bringing players back
>would be equally easy.
Now you're increasing complexity where it wouldn't matter for ASCII pfiles.
>However, the compression that was being discussed was in the context
>of someone who liked doing incremental backups every 10 days, and who
>felt text files offered better compression ratios.
They will have better compression ratios, whether they actually end up
smaller is another matter.
>ext2fs, as well as many other Unix file systems, work to prevent
>fragmentation much more efficiently than FAT/VFAT/FAT32/NTFS (yes NTFS
>tries, but its algorithms are quite bad in many cases). Besides, such
Now you're arguing the point I had, that the filesystem is optimized to
handle such cases.
>> 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.)
>
>1. If the server cached every player, each having a 3k file, on a mud
>of moderate size (1000 players) then that's 3 meg. You're saying the
>OS should cache 3 meg of data per mud?
You'll have probably 50 people at a time on a MUD, 150k. Not everyone will
be logged in at once and the OS need only care about who is actually being
accessed. (My server keeps ~40 MB of cache anyway.)
>You were rabidly arguing against pushing the limits of circle in a
>different thread. But now you're saying we should increase cpu time
>as well as increase the number of random disk accesses.
There's a difference here. Putting all your headers into one file gives
virtuall no benefit with quite a few disadvantages. Here, we're getting
all the advantages of ASCII player files and lose very little. It's a ffar
better tradeoff to have ASCII pfiles than a unified header.
>No, you are incorrect. The totalling of gold and whatnot can take
>place during the initial boot process where player names and file
I was under the impression you meant while the game was running, but ok,
I'll respond to this.
>offsets are read by build_player_index(). There is no need to call
>load_char() for such information. There's no similar method for ascii
>pfiles, unless some data is stored in a binary file that keeps track
>of this. But then you can't, say, edit gold in an ascii pfile because
>it is stored in the index.
So we extend build_player_index() to scan for gold also, since it already
scans for all the player names. Trivial.
>> 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.
>
>You love those numbers, yet they mean nothing. As I stated above,
>they are not very relevant to the ascii pfile situation.
Yes they are valid, in the world:
145 files total.
110 files are less than 10k.
97 of those are less than 5k.
87 of those 97 are less than 4k.
74 of those 87 are less than 3k.
57 of those 74 are less than 2k.
29 of those 57 are less than 1k.
It took 2.6 seconds when nothing (at all, including the directory
structure, most MUDs would have some cached) was in the cache, .8 seconds
when everything was in the cache. (Including the overhead of the
'bin/circle -c' call and loading the 1 megabyte circlemud binary.) That is
still one megabyte per second when uncached, and most of those are small
files. I expect ASCII pfiles to be around 1-3k so they would be parsed
fast enough. (I have IDE drives if you wonder.)
>> 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.
>
>Or unless they add entries to char_data that need to be stored, then
>patches much be applied in two places (though the binary system is
>simple except for the issue of database conversion, which is one of
>ascii pfiles' strong points).
char_data doesn't matter, char_file_u does, and there's spares they should
use anyway. Those spares can be automatically taken care of.
--
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