On Tue, 21 Apr 1998, James Turner wrote:
> Is this really the case? True, they can be compressed, but they will
> still take about the same amount of raw space as a binary file -- plus
> there is the inode/sector size issue, as well as inode usage. And
> with pfiles scattered across the disk of the server, it can make
> random access to them rather slow. There is much less overhead
> involved in a flat binary file than having hundreds or thousands of
> ascii files floating all over the place.
For backups and storage, ASCII is the way to go because it compresses SO
much better than binary. I don't know about you, but I keep incremental
backups of my notes/, src/ and lib/ directories (and all their subs)
everyday for 10 days back. Every 10 days, I pull out the latest and stick
in a directory where I keep things for three months. Yeah, yeah. Maybe I'm
going overboard in the safety department, but I do NOT want to lose all
that work (again!) because I didn't do my job and make backups. ASCII
pfiles would make things SO much smaller in the backups. I'm spending just
as much hard drive space on the mud as I am on backups. If I had been
smart and done ASCII player files back when I first started my MUD (I
shudder at the thought of doing a conversion now), then I'd be spending
quite a bit less space with backups.
Now to discuss the inode usage on the active and in-use files. I've seen
statements from you in the past that if everyone kept up with the mean,
then we coders could get lazy and waste a few CPU cycles here and there.
Heck, if we really wanted to we could waste tons of CPU cycles and no one
would notice because computers are SO fast now. It's thinking like that
that leads to behemoth OS's like Win95 and massivly slow programs like
QuickBooks and MSIE 4.0.
I digress. Back to the point. If we can afford to waste some CPU time,
why can't we waste space on some partially-empty or wasted inodes? After
all, everyone should keep up with the mean and according to what I'm
seeing in Computer Shopper, the mean for a new hard drive is around 3 to
4 gigs. Bah! Plenty of space to waste.
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
let you decide, but in the future please stop making up arguments that
fit your side or swapping sides when it's handy for you to make a point.
> If the desire is ease of modification of the database entries, then
> perhaps some form of editor could be made. A text-based one (not
> even ncurses, just prompt driven) could go a long way.
Now THAT would be an interesting idea that I just might work on. Make an
OLC of sort for player data and get rid of that damn 'set' command.
Nothing wrong with having a command-line way of changing player stats, but
the code is... well... horrendous to understand and modify. :( (Works
quite well, though)
> > If you don't mind including the code in the stock code, I'll wedge it in
> > future versions. (Barring objections, of course.) After that, you wouldn't
> > have to touch it unless you wanted to.
>
> Do you mean supporting both?
That's the implication that I got. Perhaps a setting in config.c or a
define in structs.h to determine which one is used?
(I saved up my 2 cents while lurking, gained interest on it, and there's
my 3.1415 cents worth that I have now. I hope it was worth the effort
that I put into not spending it until the CD matured.) ;)_
John Evans <evansj@hi-line.net> -- http://www.hi-line.net/~evansj/
Any sufficiently advanced technology is indistinguishable from magic.
-- Arthur C. Clarke
+------------------------------------------------------------+
| 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