Re: Circlemud design issues

From: James Turner (turnerjh@XTN.NET)
Date: 04/22/98


George <greerga@CIRCLEMUD.ORG> writes:

> >> What I'm getting at, James, is for you to make up your mind. Should we be
> >> mindful of hard drive space while wasting processor space when it seems
> >> to me that hard drive space is worth so much less that CPU power? I'll
> >
> >Hard drives are orders of magnitude slower than memory or the CPU.
>
> Which is why your operating system uses memory to cache your hard drive. :)

You can't rely on cache.  In a heavily loaded system, the disk cache
will be very limited by available memory.  Cache will definitely help
a great deal -- but with multiple muds on the same system all doing
the same thing, with other tasks going on as well, it will definitely
push things to the limit.

> >Again, this effectively fragments the code base (similar to having
> >threads that are only compiled on some systems).  We should pick one
> >or the other, not support two vastly different techniques, IMO.
>
> ASCII and binary pfiles can retain exactly the same interface
> (char_file_u) if desired. I don't see how that fragments the code base.
>
> You may not think of that as an optimal solution but we can still shift the
> focus to ASCII pfiles slowly while retaining compatibility with binary.

Pick one or the other.  Gradual shifts won't really do all that much
good.  If you go ascii, provide a converter function if necessary.
There's no need to straddle the fence -- Circle isn't MS Word, where
backwards compatibility of file structure makes a whole lot of
difference ;)

--
James Turner               turnerjh@xtn.net
                           http://www.vuse.vanderbilt.edu/~turnerj1/


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