FSX & Compressed Drives...Y or N?

Hi All:I was wondering if anyone here has done any tests to determine the pros and cons of using compressed drives with FSX?I first encountered the idea of using compressed drives when "optimizing" for performance with my Megscenery add-ons in FS9 from suggestions I found in the Megascenery forums.Although I believe there are a number of add-ons and perhaps some portion of files shipped/useable in FS9 itself which may be compressed, it is my understanding that most if not all of the texture and panel files used in FSX are now installed and used as compressed (ex: *.dds and *.cab) format files (in a default installation that has not been converted with some of the recent innovative FSX tweaking methods described elsewhere in this forum).I inquired about this in another thread: http://forums.avsim.net/dcboard.php?az=sho...id=357833&page=To date I haven't see any replies to this issue, and thought it might merit being made a separate thread (after all, we've gotta make FSX multi-threaded somehow, y'know!), so I have copied my inquiry from the above post into this one in the hopes it may be better addressed by the knowledgeable users here.My apologies if I have stepped on anyones toes by doing this, but I believe this may prove to be a significant tweaking factor if we are actually better off by no longer using compressed drives with FSX file formats!Any well-founded ideas on this?>Hi,>>About resizing textures, I'm wondering the following:>>Since FS9 (and also FSX) I compress my entire FS folder (incl.>sub-folders)>This will reduce the disk acces time since a file is first>loaded in memory from disk before it is decompressed.>I wonder what is the best:>Physically resizing textures with some loss of texture quality>or compressing FS folders without any loss of texture quality.>>>>{Hi Egbert:I had read that Microsoft says a computer with a 1 GHz or faster CPU can easily accomodate using compressed folders in Windows XP without a significantly perceptible performance hit when decompressing on the fly. I had been interested in seeing what this might do for Megascenery/photorealistic scenery load times in FS9, but had not yet had an opportunity to test this out.I also wondered if this was still of additional benefit when used with the higher level compression formats that began to be used in newer scenery and aircraft texture bitmaps, *.cab file types of panel gauges for FS9, and the new compressed bitmaps and panel structures used in CFS3 and FSX. The question which also crossed my mind was whether using NTFS folder compressison might end up slowing performance if the file contained within a compressed NTFS folder is itself already compressed in these newer high compression formats?This reminds me of the old days of modem communications with DOS BBS systems, when modems began offering 'hardware' compression (ex: MNP5 etc.). When files that were already compressed (ex: zip formats etc.) needed to be sent, it was found that turning on modem hardware compression in anticipation of increased throughput actually ended costing an extra 8-12% of throughput time delay as the file was read for structure, and the conclusion was ultimately reached that the file could not be compressed further (since it was already compressed) and the system then turned off hardware compression to actually send the file after analyzing the file to no net benefit, and in fact to a loss of throughput instead!One might wonder if the same principle applies with accessing and loading already-compressed files off the NTFS compressed hard disk and into FS9/FSX. Mike Gilbert/tdragger has indicated that texture (and I'm assuming other compressed file) loading has been delegated to another thread outside the main rendering thread which can run on another CPU core in FSX on multi-core machines, but this has proven thus far among multi-core CPU FSX users to do little as far as increasing the overall speed of the FS endering engine (which itself can only run on a single core in its current state of programming!).And one might wonder if the separate texture decompression/loading thread (whether on another core or not) is getting a chance to run optimally if it has to wait for the NTFS compressed folder subsystem in Windows XP to expand the compressed FS file before the FS rendering engine thread further expands the texture/panel file into working memory locations. (Note: a thread reportedly can run effectively concurrent with other threads on a single core CPU also; it is just usually expected to be more efficient depending on the type of program spawning and using the separate thread when it is offloaded to another core if available).So like you, I am curious if one can/should use compressed folders with the new compressed file architecture now implemented in FSX when concerned with maximizing even a few extra frame rates of performance on our computers to deliver the best FSX performance we can get.Remembering that "as real as it gets" requires optimized software and hardware performance in order for the sim to deliver that experience, perhaps Mike/tdragger or one of the other ACES staff would be kind enough to comment on this NTFS compressed folder issue here?And if there are others here who have a reasonably authoritative insight on this process, could you share your insights and suggestions too? :-hmmm Thanks for your input on this everyone!} :-) GaryGB