Re: [CODE][ASCII PFILES] Bug Fixes

From: Daniel Koepke (dkoepke@california.com)
Date: 01/22/99


> And as far as someone on this post claiming the ASCII loads faster
> or as fast as binary and saves memory My SE teacher at my graduate
> school got a great laugh at your expense.

He shouldn't laugh without knowing the full story.  First, what is
gained by the binary files compact record format in terms of speed and
size is lost by the fact that the binary files contain more
information (specifically, deleted characters remain in the file).
Second, while it might not be faster or even as fast as binary file
loading, the difference is so slight it probably doesn't matter.

An ASCII format offers significant advantages over binary.  They're
far more portable because you don't have to worry about little/big
endian.  Also, they're more flexible: you can add fields to ASCII
files easily.  With binary files you must write a conversion program.
Binary files--or, at least, those consisting of multiple records--are
more succeptable to corruption.  In an ASCII file scheme, or even a
one-record-per-file binary scheme, one corrupt record cannot damage
the rest of the data, making error recovery easier.  ASCII files can
be hand-edited.  To some this is a security risk (although, it's
really your fault if you aren't setting permissions correctly), but
I would view it as a plus: if you want to change data without
starting the MUD, or if bad data in your file is causing the MUD to
crash when you attempt to login, you can fix it or test other
values to help isolate the weak points in your loading code.

As far as saving memory: highly unlikely.  You're loading the same
exact data into memory.  If you meant disk space, it's not such a
laughable idea.

-dak


     +------------------------------------------------------------+
     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     |  http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html  |
     +------------------------------------------------------------+



This archive was generated by hypermail 2b30 : 12/15/00 PST