The only fixed rate in this kind of assessment is the data decompression rate, which is probably fixed, or as near fixed as makes no difference, given the speed of modern processors. After that the difference between sizes of hard drives, speed, rates of movement of the read/write head, even the temperature within the computer all make a difference that is only measurable on an individual basis. So there can't be a defintive answer, except that two of us now say there is no noticeable difference, others say otherwise. So the best conclusion is: Try it if you like, you can't do any harm and you only waste time, nothing else. Set it to compress overnight and go to bed. Launch FS in the morning and experiment.The only reason I don't decompress my FS folder is that everything else on that hard drive is already compressed, as it is used for file storage with only FS as an active .exe file. And FS itself is about 10 gig, with the Addon Scenery folder on a separate, also compressed, drive. To decompress everything I might as well book a holiday for a week and then leave the computer to get on with it!In fact, you don't need to compress the whole FS folder, you can even compress just parts like the scenery, texture or aircraft folders - that should give you a good idea of the likely impact on your system. Finally, Windows XP doesn't have a swap file, it uses a Paging File which is appreciably different. I have never seen any technical document that discusses the relative speed of data transferred to the paging file from compressed and non-compressed folders - in truth it can't make a difference as the Virtual Memory is accessed only AFTER the decompression algorithm has done its work, surely?. Data is transferred to the Paging File in ready-to-use format, I think.Allcott

Alright, I tried to avoid this on the first post to avoid making it too lenghty and boring to read, but if you insist... Back to the virtual memory concept.As you will find in pretty much all Computer Design and Architecture, Virtual memory, and thus all the memory hierarchy systems, is based on two main concepts:- Temporal locality: Usually, when a process accesses certain data, it will probably be accessed again soon. If you have any experience in programming, you can testify that most programming tasks are based on looping and recursion, so the same data is accessed over and over.- Spacial Locality (this is the one that matters for this subject): generally, if some data is read or written, then it is likely that the next piece of data you need will be physically near the one accessed before. Think of this as a library. When you store some books on a library about some subject, you store them together. When you need to retreive two books about that subject, it is likely that they are near each other. So, back to our problem, soon you will understand what this was all about...lolDisk access times can be decomposed in different things:1- Seek time - The time the needle needs to reposition itself to the read the proper track on the disk. Now comes spacial locality... If things are very close together, this is always a very very small time, almost irrelevant.2- Rotational delay - As you know, our hard drives are magnetic disks rotating around. After the needle is positioned, it needs to wait for the disk to rotate so that the sector we want is below it and we can read the data.3- The actual transfer time, which is dependant on the bandwith available to the disk.So, according to our locality principles, the seek times should be very small.Now to the decompressing overhead:Nowadays, our disks use a technology called DMA (direct memory access), which details I won't be going into, but it takes the workload of file transfers to and from the disk, away from our processors. So, if we are using uncompressed folders, our processor requests the transfer from the hard drive and then moves on to other tasks while the transfer goes on, handled by the DMA controller, on the mainboard. When it is done, we can use the data right away.Using compressed folders, we have to request the tranfer from the disk and then the processor has to go through all the data retreived to uncompress it, which takes MILLIONS of clock cycles to accomplish. This overhead is clearly much bigger than the difference in disk access times benefit from reading less files.Also, reading many small chuncks of data from the hard drive is very often less efficient than reading one larger block of data. As transfer sizes decrease, the transfer overheads (which remain unchanged, reagrdless of the transfer size) become more and more important to the global disk transfer time.Hope I have been clear enough...I can recommend a good source of info on this subject (transfer times, overheads, etc..), which is the book I have used to study on the University:Computer Organization and Design, 2nd Ed.D.A. Patterson & J.L. HennessyMorgan Kaufmann Publishers, 1997Very very nice book, I can recommmend it to anyone interested in these subjects ;)

>Finally, Windows XP doesn't have a swap file, it uses a Paging>File which is appreciably different. I have never seen any>technical document that discusses the relative speed of data>transferred to the paging file from compressed and>non-compressed folders - in truth it can't make a difference>as the Virtual Memory is accessed only AFTER the decompression>algorithm has done its work, surely?. Data is transferred to>the Paging File in ready-to-use format, I think.>>AllcottI know it doesn't... I don't want to go into details here, to keep this readable for others. Used the term "swap file" because it is a term most can understand...And yes, paging is very different, but we don't want to go into page tables, page faults, and all that stuff...BUT, you got something there.. I thought data was transfered compressed to the "virtual memory" (just for clarification, as it seems we want to have absolute correctness in our terms, "virtual memory" is the whole system, including paging, page tables, main memory and caches level 1 and 2) and decompressed as it is used.. But the way you described it seems to make much more sense in fact, as you minimize the overheads for decompression, because you only need to do it once...Good point, never though of that...lol

But anyway, the point I was going to make before going into all the tech discussion is that it might only make a difference on your loading times, not on the performance of the sim. If you are looking for benefits, bring your stopwatch out and time the loading process, and don't go looking for better framerates or smoothness, you are looking in the wrong place.You MIGHT notice some diference in blurries, but this is just a guess

In my experience what is more important than compression or not compressing folders / files - is having a contigious "paging file" preferrable not on the same physical hard drive as the OS.I have no doubt all of you are accurately reporting what you are seeing - but without identical systems - including identical files loaded in an identical order - you are comparing apples to sweet potatoes.There are plenty of benchmark programs out there to record and document your performance if anyone cares to make the test. And document some real numbers.However as we all know - perceptions are more improtant than reality.FS is a extremely complex game which uses a lot of various system resources and devices. There are many ways to get your computer unbalanced and cause issues. There are a few ways to optimize your system - and those ways are different for almost all of us.I have two computers - a P3.2 with 2GB RAM ATI 9600 256MB, and my old P1.8 with 512MB RAM and a 128MB Nvida card. They each take very different configurations and settings to get the best performance from each.And I'm sure I could do better with each of them if I wanted to give up flying and spend my time tweaking.There are normally two reasons to consider disk compression - according to Microsoft1. Save disk space,2. Change system performanceYou'll have to test #2 yourself.As far as disk space - most people with large aircraft inventories can achieve a 25-40% space saving by using only one lightmap file or one set of lightmap files for each model. By placing the _L.bmp file in the main Texture folder - you can avoid a lot of duplicate files.The key thing about disk space is that you need to keep about 20% of the disk as free space. If it drops below 15% defrag will not run.

>>Do not compress your folders. This will no doubt decrease>>performance as there's a overhead associated with>>decompression. >>You are clearly mistaken. I have done many, many tests with>compressed and uncompressed folders and I see absolutely no>impact on my system when I compress F9 folder. Don't know>about slower CPUs but on mine - I decided to have them>compressed since it saves me disk space without any>performance penalty whatsoever.>>Michael J.Impact is different. You just said it. It will not show due to you're system specs, it will not show in most modern PC's. But overhead is there, whether it impacts performance or not. That's what I meant. It may sound simplistic but it's true. Unless I have a serious problem regading disk space, I won't be using NTFS compression. And as I won't be enjoying extra FPS or lesser stutters in FS, I won't be using disk compression. If anyone can prove that the sim is smoother due t disk compression, I'll gladly start using this feature right now.Cheers,Keith

>It may sound simplistic but it's true.You bet it is simplistic, therefore it is not true, since it conveniently skips other "overheads". Because if "overheads" are your concern you should examine what is the HD overhead in delivering extra data from HD to the memory. You seem to have a very narrow understanding of computer hardware as there are many "overheads" you chose to disregard.Michael J.

For contigous page files, optimised master file tables, and for defragged performance optimised data use DISKEEPER. Get a demo and try it for yourself. It runs as a Windows service. Set it to "set and forget". I have mine set to "everyday, except 6am to 3am" so it runs between 3am and 6am in the morning, when I'm not using my PC. Also, check MFT allocation on your FS drive. Most probably, it'll be less than required. Diskeeper will expand and fix it for you.I've all but eliminated stutters after discovering Diskeeper. The only time it get stutters or rather pauses is whe I switch views around dense 3rd party scenery (simflyers, fly tampa, oss)Keith

Guess you need to check this on your very system.Each system behaviour can be different. Depends on OS, hard drives, memory, processor speed etc.As badly designed as it may be, Windows XP is very complex under the hood. In fact, you never know beforehand how it reacts in a given situation.To a certain extent, you can try to somehow "tweak" what the paging file algorithm does, by e.g. refusing kernel portions to be swapped out, increasing the time DLLs are kept in RAM and not paged etc. Windows is a lousy memory manager, much time is spent on housekeeping the virtual memory (run FS on a 2Gig machine - you'll find WinXP swap like #### ('cause Windows swaps by default, no matter how much memory you got) whereas half of your RAM is untouched - that's what efficient ressource management is all about!)But in the end, you need to find out for yourself whether the overhead created by decompressing the files is greather than the one the data transfer from the drive to the main memory is or not.Andreas

> This overhead is clearly much bigger>than the difference in disk access times benefit from reading>less files.>No it isn't - it's just another unproven assertion!

I have yet too see you present any evidence about what you are saying. You didn't.So, I'm tired of all this, if you want to compress, do it. If you don't, don't do it.Your problem, your computer, your decision.

I simply said what I observed. That doesn't need evidence.

After reading about this about a year ago in another thread here, I compressed my FS9 folder. Sure, it saves a lot of space, but I have not noticed any detrimental effect whatsover when using the sim.I pre-set my page file to a different drive to my O/S to aprox 1 1/2x my RAM size (1.5gb page file), and everything runs pretty well.You'll never eliminate those occasional stutters by compressing, though I must say, it seems to reduce them slightly.....on my system (Athlon 3000XP+: 1gb DDR400 RAM: BFG Geforce 6600GT-OC), and it's more of a 'feeling' thing than a definate quantifyable fact!!If you do compress your FS9 folder, just remember to defrag the drive afterwards, as compressing folders does rather scatter files all over the disc, which would negate the benefits of the tighter, closer concept behind compression!!