G
garrydt
Does enabling compression on your C:/ drive impact
performance; if so is it a real killer?
performance; if so is it a real killer?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
A
Al Dykes
Does enabling compression on your C:/ drive impact
performance; if so is it a real killer?
I've used ntfs compression many many times, for about 10 years and
have never seen any downside to it.
You can compress c:\, and all subdirectories. It will give you a
message apbout pagefile. Ignore it. How much space you get back
depends on your data, MP3 and jpg files are already compressed.
If you run an application that has a database on your C drive you
should, after compressing, uncompress the file or folder that contais
your data. For th epurpose of this duscussion, a "database" an
application that updates data records in-place, or inserts records in
the middle of the file istead of just extending the file.
If you miss some database no damage is done, the application
may run slowly when yo are adding or updating data.
A
andrea catto'
here's what I learned my self empirically,
'IT DEPENDS'
compression is NOT always working, in which case it's a waste of CPU versus,
no gain, slower for nothing bascially.
some times it does work but minimally, not a lot of gain.
in some cases it work very well, for instance in text files, or easily
compressible data, in which case here's what I have seen.
in case of frequent access, it may deteriorate performances because of
the CPU time taken to compress/decompress
and in other cases I found compression 'could' actually improve disk
usage immensly and YET improve timing too.
let me describe this 'paradox' of total improvement, if a file can be
compressed, the clusters involved in read-write are also less then normally
needed, therefore in this case it coult be beneficial to use CPU time versus
disk time, because CPU is faster in most cases then disk.
finally.
you might want to compress data that is not commonly/frequently used, such
as a whole directory branch.
or could also want to 'try' compressing certain files or directories that
contain text or stuff you know is quite reduntant in its content and
possibly over the size of many clusters to see some benefits.
'IT DEPENDS'
compression is NOT always working, in which case it's a waste of CPU versus,
no gain, slower for nothing bascially.
some times it does work but minimally, not a lot of gain.
in some cases it work very well, for instance in text files, or easily
compressible data, in which case here's what I have seen.
in case of frequent access, it may deteriorate performances because of
the CPU time taken to compress/decompress
and in other cases I found compression 'could' actually improve disk
usage immensly and YET improve timing too.
let me describe this 'paradox' of total improvement, if a file can be
compressed, the clusters involved in read-write are also less then normally
needed, therefore in this case it coult be beneficial to use CPU time versus
disk time, because CPU is faster in most cases then disk.
finally.
you might want to compress data that is not commonly/frequently used, such
as a whole directory branch.
or could also want to 'try' compressing certain files or directories that
contain text or stuff you know is quite reduntant in its content and
possibly over the size of many clusters to see some benefits.
A
Al Dykes
here's what I learned my self empirically,
'IT DEPENDS'
compression is NOT always working, in which case it's a waste of CPU versus,
no gain, slower for nothing bascially.
some times it does work but minimally, not a lot of gain.
in some cases it work very well, for instance in text files, or easily
compressible data, in which case here's what I have seen.
in case of frequent access, it may deteriorate performances because of
the CPU time taken to compress/decompress
and in other cases I found compression 'could' actually improve disk
usage immensly and YET improve timing too.
let me describe this 'paradox' of total improvement, if a file can be
compressed, the clusters involved in read-write are also less then normally
needed, therefore in this case it coult be beneficial to use CPU time versus
disk time, because CPU is faster in most cases then disk.
I differ.
I started using NTFS compression on entire C drives when our PCs were
486/66 systems and we were doing very CPU-intensive stuff. If there
was any CPU cost we would have noticed in, believe me. I spent lots of
time looking at perfmon data.
Today's CPUs are literally 100s of times faster, and generally
underused. There's plenty of unused cycles foating around. Most IDE
controllers use lots of CPU cycles to move data to/from the disk. If
you can reduce the # of sectors to read you reduce the CPU time to
read that file by a similar amount. This wins big-time for highly
compressed files.
If you are storing huge files that are already compressed (mp3, mpeg)
you won't get any space from compression, but I'm not sure that the
cost of the having compression tuned on is measurable. These days
I work with huge TIFFs (60MB) in Photoshop. My TIFFs don't compress
much and I don't see any win, or loss, to file system compression. I
haven't played with PSD files yet, which may be even bigger.