At 02:56 AM 2/4/00 -0500, you wrote:
> Using ASCII pfiles instead of binary adds a great deal of flexibility as
>far as adding new stuff goes, so I decided to add them to the mud I'm
>working on. However, it takes the mud a lot longer to get through the
>save_char function, as it's doing a lot more work than before.
I recently added my own ascii pfile system. I didn't start from any that's
out there, I just started from scratch so I could go in stages, allowing me
to first have both binary and ascii (save to ascii only, load from ascii if it
exists, and binary if not), so I could transition without a pwipe. Then I
linkloaded every player (via an interpreted C script, not by hand :) and had
each save, creating all the ascii entries, then I removed the binary piece.
> Such are the consequences of having a variable-length player entry. I
>did go through the save_char function and changed all the fprintf's to
>sprintf(buf + strlen(buf), ...)'s, and a single fwrite at the end. I also
>attempted to optimize it by combining all the sprintf's that I could. In
>the end I made save_char about twice as fast as it before (btw, I'm using a
>heavily modified version of Samedi's ASCII pfile system) , but the speed is
>still noticably slower than a port of the mud running on the same server
>with binary pfiles.
I don't see any noticable slowdown of save_char() at all. My save_char() is
just a bunch of fprintf()'s. One approach I took is to not write out fields
that
are 0 anyway; instead I memset() the structure to 0 in the load routine
before parsing the file.
I have 65 levels in the mud; I advanced a player from 1 to 65, and it happened
faster than I could blink.
+------------------------------------------------------------+
| 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 : 04/10/01 PDT