Re: [CODE][ASCII PFILES] Bug Fixes

From: Patrick Dughi (dughi@imaxx.net)
Date: 01/22/99


> should ask yourself do i realy want ASCII Pfiles whats the diffrence? The
> advantages? disadvantages and if you cant answer any of these depending on
> run time execution load or diffrence between ide or scsii ASCII saves
> (Ie if you on a SCSII3 and move to a non scsii u screwed if you have
> ASCII), you should stick with the stock binary pfiles which are handled
> _well_. 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. sorry.
>

        Not to harp on the point too much more, since its been covered in
its entirety before..

        Ascii is fast 'enough'.
        Ascii is easier to work with (add/alter/debug)
        Ascii uses same memory size.
        Ascii, if done well can save space, contrary to popular belief.

   Well, this last one hasn't been covered, but i've found it to be true,
especially on muds that i've adopted.. there's a lot of unused expansion
space in binary files, and a lot more for strings that don't reach their
limit or are not used.  Take binary rent files - for most objects, all
that needs saving is their item number, to be reguritated upon load.  The
rare exception to that with an extra affection (enchant weapon, etc).
Currently though, stock circle saves nearly the entire memory structure of
an object (obj_elem is pretty close to everything) right in there.  However,
you can squeeze this space down quite a bit if you only save what needs be
saved.  Sides, its childs play to just use compression algorithms to
shrink them down if that's unreasonable (though it increases your load
time)
                                                PjD


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