John Evans <evansj@HI-LINE.NET> writes:
Regarding compressibility of text files. Yes, they are more
compressible. But that is because they have a large amount of
redundant information. A very large amount. For instance, to store a
single integer in a text file, you need a line for it, a label, a
delimiter, whitespace, the number itself, and a newlinw. Even if it
is one digit, that is 2 + 1 + 1 + 1 + 1 = 6 bytes, assuming a two
letter label.
Compression also works on binary data. Not as efficiently in some
cases, but that is because there is in general less inherent
redundancy. If you wished do incremental backups of the player
database, I believe a program called xdelta would work quite well --
it is like diff, except functions on binary files.
Revision control is an excellent way to make backups efficiently, as
well as keep track of past progress. I would highly recomment the
PRCS program to any who wish to do any serious development. It is
quite useful and reliable. It is similar to RCS and CVS in function,
though it is project based instead of file based. The official site,
which has a link to xdelta as well, is
http://www.xcf.berkeley.edu/~jmacd/prcs.html
PRCS is an excellent tool, and I use it regularly for my source tree
as well as world files and lib/text and parts of lib/misc. It also
serves quite functionally as a disaster recovery tool.
> 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.
>
> 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.
The CPU time I was speaking of was adding function call overhead in
place of macros. Hard drives are orders of magnitude slower than
memory or the CPU. Further, in a multiuser environment, drive access
is considerably more noticeable than CPU usage spikes. I do not
appreciate your tone. If you wish to have discussions, the put them
here. Do not put personal stabs here, as you have already done once
-- to which I replied by email, where such things belong.
> > > 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?
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.
--
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