SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Pastimes : Dream Machine ( Build your own PC )

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: AHM who wrote (2502)9/15/1998 7:49:00 AM
From: Spots  Read Replies (1) of 14778
 
Compression questions:

1. Does compression use algorithms that can be misinterpreted like
Stac did or is it simply a better way of utilizing space?

I'm not sure I understand this question. The algorithms are
built into NT, and NT knows how to run them. They are applied
on a file-by-file basis. Even in a "compressed" directory,
each file is distinct and has its own compression attribute.
"Compressing" a directory gives the directory a compressed
attribute, which is inherited by files that are written there.

There aren't any fake "compressed drives" residing in visible
files on "real" drives (i.e., partitions) a la Stacker and
Drivespace, if that's what you're asking. It's no-kidding
built into NTFS, not layered on top.


2. Is there any operating speed loss when working with compressed
software or data?


That depends. Yes, there's more CPU overhead, but whether you
notice it or not, or can even measure it, depends on many
factors. In some cases you get performance improvement.

Transfers to and from disk cache in memory are
slower than they would be without compression, because
the data is being compressed/decompressed as it's transferred.
How much slower depends on, for instance, the L2 cache, the
L1 cache, the relative speeds of the processor and memory,
the size and compressibility of the data, and probably other
things I haven't thought of.

Transfers to and from physical disks are, on the whole,
faster than they would be without compression, simply because
there's less data to transfer.

Decompression is several-to-many times faster than compression,
so reading data/executing programs has the least overhead.

As a general rule, it's not advantageous to compress .exe
files because they don't compress well. On the other hand,
once (slightly) compressed, they are quick to decompress.
The penalty is mostly in the compression, so if exe files
reside with large compressible files, you might want to
compress the directory anyhow. Who cares how long it
takes to install an EXE file?

To net this out, you just have to try your own situation
and see if it matters. As a point of reference, on a Pentium
Pro 200 (slow by today's standards), I don't
find any practical difference most of the time. However,
that's a subjective impression, not a measured result,
and it definitely depends on what you're doing.

For grins I just copied an 11.3MB (uncompressed) database file
into compressed and uncompressed directories (3 trials each)
with the following results:

Compressed copy: 7.21 seconds; compressed size 3.8MB.
(Average of 6.46, 8.01, 7.17)

Uncompressed copy: 8.43 seconds.
(Average of 7.92, 8.60, 8.76)

In this case the compression overhead was clearly less than
the disk improvement. Also, as you can see from the variation
in the samples, whether you get an overall improvement depends
on more than just compression. Note this was NOT a rigorous
test.

This answer is already long, but I have to add that performance
can be measured in various ways, such as resources consumed or
throughput, so any answer depends on what your after as well.

With compression, overall you use your cpu more
and your disks less than you would without it. Probably.

If you're computing pi to 80,000 places
in the background, compression will probably slow that down.
You might call that a performance hit. If your cpu stays
87% idle and you're hitting disks a lot with highly
compressible files, compression will probably speed that
up from start to finish (throughput) unless the cpu is slow.
If your processor is slower than mine, get a new horse <g>.


3. Is NT compression the same as disk defragmentation and if it is
should there be scheduled "compression" runs?


No and no.


4. Can compression be reversed and compressed files restored to their
original status before compression? If so, how?


Yes. Compression is an attribute which appears in the file or
directry property sheet. Check it and NT compresses the file.
Clear it and NT decompresses the file. You can be as selective
as you like.

Trivia Note: If you move an uncompressed file into a compressed
directory, it will not be compressed. You have to copy it
there to get it compressed in the process. That is, if
you move the file within a partition. "Moving" a file
from one partition to another is really a copy-then-delete
operation, which will compress the file. Vice versa for
moving a compressed file to an uncompressed directory.
Compression is an attribute of the file; you must
create the file to inherit the attribute from the directory.

Spots
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext