On Wed, 22 Apr 1998, James Turner wrote:
> 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.
This won't happen. It would defeat several of the advantages of ascii.
> Compared to reading a binary file, the parsing will be orders of
> magnitude slower.
How so? I've mentioned the new version reads and writes the entire file
(using fread/fwrite), then parses memory to ocnvert the data to something
usable. As you stated, "Hard drives are the real bottleneck." I'm not
going to argue that ascii pfile are faster. I haven't done any testing so
I've got no data to make or break that claim. As far as I know, nobody
else has this data, and this speed argument is based on a lot of
assumptions.
> 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.
This would be very time consuming on a big mud using binary pfiles. I
know, because I've seen the seconds tick by while I waited for a slow
Sparc 10 to parse 1000 players (shortly after a purgeplay maintenance).
There are two much better ways of getting this kind of data. You could
either put it in the player_table, or you can use an offline script or
program.
grep "Gold:" lib/pfiles/*/* ; awk '{printf $2}' ; total
(excuse my syntax)
> 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 a good point. It will require a little more effort from the people
who contribute patches/snippets. Very few patches require pfile changes,
though, and when they do, it's usually a small change, such as the olc
zone variable used in oasis. I've contributed a fair amount of circle
code and can't recall ever adding a pfile variable.
> 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.
Since I'm probably going to be working on the modularization, I'm open to
suggestions on inprovements. What makes it not quite right?
Sam
+------------------------------------------------------------+
| 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