Re: ASCII pfiles and speed

From: Mark A. Heilpern (
Date: 02/04/00

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
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:  |
     |  |

This archive was generated by hypermail 2b30 : 04/10/01 PDT