Windows Swap File - Test Report - Defragmenting Tutorial And Optimization Tips

Community

Aggiungi lista preferiti Aggiungi lista nera Invia ad un amico

------------------

Crea

Profilo

Blog

Video

Sito

Foto

Amici

Esplora

WINDOWS PANES
<< Tips & Tricks WINDOWS PANES
Tips & Tricks >>

Windows Swap File - Test Report and Defragmenting Tutorial

By the way, you've just surfed into a website very rich in information about Windows software, tips, tricks and tweaks. Don't leave without exploring the resources listed on the main page.

Author/Publisher:

Microsoft

Contact/Address:

www.microsoft.com

Test Report - Description

The Windows swap file (also termed - more or less correctly - swapfile, pagefile, paging file and, most appropriately, swamp file) has been a point of controversy since the earliest days of the Windows OS. There are endless discussions and postings on the Net dealing with its optimal size, location and properties.

Test Report - Pros

With modern memory-hungry bloatware produced by Microsoft & Co., the Industry has decided for you: you have no choice left, you simply need virtual memory (as you need a 10 GHz Pentium, a 60 TB disk etc.) Don't you fool yourself thinking that it's you who decide.

Test Report - Cons

Virtual memory is terribly slow. While the use of paging files does enable an OS to run several huge applications at once (which is called multitasking in nerdspeak), it reduces (not improves) the overall performance of a system.

Test Report - Optimization Tips, Tricks and Tweaks

Properties, and Changing Them

Many a word and many a nonsense has been said about the so-called permanent swap file (the term simply indicating a swap file that is fixed in size, so Windows can't resize it and, consequently, can't toss its pieces up and down your HD). This is achieved by manually setting the same min and max sizes for the swap file; if you only set the min size and leave the max for Windows to manage, you get a so-called semi-permanent swap file, with a fixed min portion and a variable leftover portion. At the present state of things, the latter is the only reasonable solution, since with Windows you virtually never know how much your virtual memory may grow! So deeply true is this that it's worth repeating: with Windows you virtually never know how much your virtual memory may grow! Let's take my case (Windows 98, Internet Explorer 5.0 & 5.5) as an example: if I happen to read several pages of a multiple-paged HTML document stored on disk (you probably all have such HTML books somewhere on your disks, say, a tutorial, a FAQ, a manual etc.) and jump back and forth a little, Internet Explorer 5.0 suddenly starts bloating up the swap file and doesn't stop even if I cease navigating between pages altogether. I may even leave the machine alone: when I come back in an hour or less, Internet Explorer 5.0 has blown the swap file to a disproportionate 500 MB or so. I suspect this must be a bug in Internet Explorer 5.0, which apparently keeps allocating more and more memory, although it will never really need it (it should be mentioned that I've configured it to use a proxy, which may be the culprit). The only solution is to close the browser without further ado. Hence, setting a maximum size, any maximum size, for your virtual memory - even if you set it to 1 GB - means possibly confronting Windows with an out of memory situation, and that means asking for trouble! Accordingly, as regards modifying (that is, specifying) the virtual memory max size, there's no question at all - you should definitely leave it at its default (unlimited). Now, about the min size. If you don't specify it, Windows may theoretically (if you have loads of free physical RAM, for instance) shrink the swap file to 0 or, more truly, to a couple of MB, which means that as soon as it gets larger again, Windows will scatter it all over the HD, producing a terrible fragmentation and, consequently, getting exceedingly slow. Thus, as Microsoft themselves put it somewhere in the Resource Kit Book or in the MKB, the most you can do for your swap file is provide it with plenty of contiguous disk space where it can thrive without getting excessively fragmented. The only way to do this is by defragmenting the free space on your disk with virtual memory disabled, and then enabling it. Or, by ensuring first that a swap file of certain size (say, 500 MB) is contiguous, and then setting its minimum to that size: that way, and that way only, at least its first 500 MB are sure not to get fragmented. Ever.
Now, the other hot issue with the swap file was its size as such. I've heard it argued many times that the formula "set the swap file to two, three, four, or even five times your installed RAM" is ridiculous and obsolete and was only valid in Windows 95. Well, alas, my personal experience with Internet Explorer 5.x w/ proxy described above suggests otherwise. I'm sad to say that, no matter what people theorize about it, even with 128 MB of RAM and Windows 98, a bulky 512 MB swap file simply won't stay unused. This raw fact may be sad, but it's nonetheless true.
And now, a word or two about the (in)famous ConservativeSwapfileUsage=1 setting that should supposedly improve your system's performance by forcing Windows to use up all available RAM before even thinking about swapping. Well, I've tried it and, on my system, there is no noticeable change before the RAM is used up - and there is terrible degradation as soon as the swapping begins. The whole system almost grinds to a halt. Moreover, I simply think that the swap file may not be the only culprit here - the notorious Windows "thrashing" may apparently take place for the most disparate reasons - write-behind caching, icon cache (re)building, temporary file creation/deletion etc. etc. That's why I'm increasingly convinced that it just can't be eliminated - unless you dump Windows and choose some other operating system, that is ;]

Defragmenting Tutorial

Optimizing? Tweaking? Enhancing? Simply Moving!

Now if you know, as I know you know, anything about hard drives, spin rates and radial velocities, you can make the simple inference that if you want a chunk of data to be read from (or written to) the disk at maximum speed, that data must be located on the outer cylinders of the platter(s). How may you achieve this enhancement? Well, many sites reccomend that you should get a trial version of Norton Utilities with its Speedisk util, which will do this task for you, and then uninstall the program. Or, that you get a similar utility from Mcafee/Network Associates, or whoever, and then uninstall the program. I assume this method would work as a breeze, since I myself have used it extensively back in the good old days of Windows 3.11, FAT16 and 8.3-type filenames with a good old version of Norton Utilities (8.0 I think it was). But since Microsoft started inventing FAT32, long filenames and so on, I just got fed up with buying a new version of Norton Utilities every three weeks or so. Not to speak of the other cool feature of Windows software: the uninstall procedure. Be honest to yourself, is there any software package of which you are absolutely sure that it uninstalls everything it installed?... See? That's why I resorted to freeware, shareware and ingenuity. Now, with Windows 95 there was a problem in that its native Defrag utility wouldn't re-sort the files while defragmenting your disk (although there were rumours it did take into account the files' access date, placing the most recently accessed files at the beginning of the disk - I just never dug deeply into that, at least not enough as to verify, or refute, those rumours). I took another shortcut, which I'll call

Moving It the Hard Way

To cut a FAT story thin, the idea was this: if you create a second partition on your HD, move all your data there, reformat the first partition and assign it as the Windows paging drive (or simply copy the swap file there), Windows will automatically write a contiguous, unfragmented swap file on the outmost cylinders of the first partition. Then, all you have to do, is copy the contents of the second partition back onto the first partition and dump the second partition, and voilà, the task is done. Of course, I would under no circumstances want to accomplish this using Partition Magic, since buying it would be tantamount to buying Norton Utilities, and that's not the spirit, now, is it? So I naturally resorted to freeware/shareware partition managers and must admit there are at least two great ones out there. If you are a destructive person and want to play with your system beyond recovery, try them out. Otherwise, I would only recommend them to extremely savvy users and to people who are going to use them on spare, non-critical machines. These utilities are: FIPS, Ranish Partition Manager and Zeleps's Partition Resizer. They all work well and they all work only from the native DOS prompt.

Moving It the Way Gill Bates Never
WANTED

You To, Or,
Muggoshot's Best-Kept Secret

Now, the second method is valid in Windows 98 only, and it is so utterly simple I just can't stop wondering how noone has thought of it before. What doesn't bug me at all, on the contrary, is the fact that, despite its sheer simplicity, neither Microsoft themselves, nor any of the big software companies that produce Windows utilities, have disclosed it so far, although there has been a vivid interest on the part of Windows users. How would they sell their utilities, if they admitted that everything those utilities offered might be achieved with the aid of the OS alone? Do you still naively believe there is healthy competition between them? Wouldn't it be much more fair to say there's some sort of sick conspiracy between them, a conspiracy against us users? With the sole purpose of draining our pockets to the last nickle?
Well, anyway. Let's concentrate on the method now, step by step:

What does Win 98 Defrag do, in essence? It defragments files and free space, contemporarily rearranging, if you tell it to, programs so they start faster. If you look into it at least superficially, you soon find out that there's an Applog subdirectory in your Windows directory, in which optimization data are stored for defragmenting programs so they start faster. If I remember right, the information is stored by taskmon.exe which gets launched from the HKLC\Software\Microsoft\Windows\CurrentVersion\Run key of the Registry every time Windows starts.
Now if you look in this Applog directory, you immediately see that every file is named after a program that is supposedly to be optimized in the defragmentation process (the extension exe being replaced by lgc), with the exception of three files: Applog.dtc, Applog.ind and Optlog.txt. Well, here's where a little ingenuity or intuition - or, rather, just plain common sense - kicks in: while Applog.dtc, Applog.ind are unreadable binary files of some sort, Optlog.txt is evidently a plain text log. So let's read it! What do we find? Well, in my case it begins like this:Program Launch Optimization Log - Created Mon Dec 31 18:43:24 2001 Programs Eligible for Optimization: Ord Flag ProgName Uses LastExecDate Program Path 1 RUNDLL32 13539 2001.12.31 C:\WINDOWS\RUNDLL32.EXE 2 I_VIEW32 3111 2001.12.29 C:\PROGRAM FILES\IRFANVIEW\I_VIEW32.EXE 3 OSA 2960 2001.12.29 C:\PROGRAM FILES\MICROSOFT OFFICE\OFFICE\OSA.EXE 4 IEXPLORE 2630 2001.12.31 C:\PROGRAM FILES\INTERNET EXPLORER\IEXPLORE.EXE
The list is so self-explanatory, I won't even comment on it. I'll just say that, in my case, Rundll32 is obviously the executable that gets launched far more often than any other, so if I launched Defrag with the option rearrange programs so they start faster checked, Rundll32.exe would hopefully get moved right to the beginning of the disk. Now isn't that exactly what we are trying to achieve, except that we would like to substitute Win386.swp for Rundll32.exe? You're beginning to get it, ain'tcha? Well, so did I. There was still a little trial and error and troubleshooting, but it was a piece of cake really from that point on.
First, I renamed a large 200 MB *.avi file, but couldn't get it to work. I suppose Defrag (or, more probably, Cvtaplog.exe) checks if the files to be optimized are real executables. Anyway, I was relieved to find out that, luckily, Win386.swp is similar enough to an executable to fool Defrag into defragging it. Unfortunately, I was soon to find out that Defrag has far more peculiarities than that. For example, the above list of programs eligible for optimization doesn't neccessarily mean they will be put on the beginning of the disk, it only means they will be saved contiguously with any libraries they use! Although Defrag does place programs on the outer cylinders sometimes, that apparently depends on sheer luck - and is somewhat easier to achieve if you haven't defragmented your drive in a long while. Moreover, not every Win386.swp fools it. Obviously, some swap files are more like executables than others.
Of course, there are several minor catches and workarounds you must keep in mind. First, Windows won't defragment its current swap file, so you must defragment its duplicate (the easiest way to do this: exit to DOS, rename Win386.swp to any other name, say Win386.bak, return to Windows, rename Rundll32.exe (or any other program that comes first in your Optlog.txt) to anything you like, say Rundll32.bak, rename/move Win386.bak to \Windows\Rundll32.exe and launch Defrag. It may sound complicated, but it's not.
Just remember to set the minimal swap file size to a fixed number, and to rename the fake Rundll32.exe back to Win386.swp afterwards (first deleting the existing Win386.swp, of course) and Rundll32.bak back to Rundll32.exe again. The only minor drawback that can occur is if your free space is fairly fragmented and there are free clusters at the beginning of the disk: in that case, when you restart Windows after renaming its Win386.swp to Win386.bak, it may recreate its new Win386.swp all over the outer portion of the disk, where you would like your permanent swap file to reside. So it is good practice to defragment the first 200 or 300 MB of the disk beforehand, until there remain no free clusters where you plan your swap file to be. Or, if you have loads of physical RAM, to disable virtual memory after renaming Win386.swp to Win386.bak and before restarting Windows. You do this by adding the right entry to System.ini, of course.
If you are doing this without a third-party defragmenter, you will doubtlessly make extensive use of Defrag.exe's Details view. Well, although it isn't hard to tell the swap file from any other files, since it is marked in red (unmovable), it does get a bit confusing when you start renaming and switching files back and forth; so remember, to easily locate a file in Defrag.exe's Details view, just temporarily set its hidden and system attributes and it will show in red (unmovable).
Be warned, though: this method may turn out to be terribly time-consuming to implement. The description above is only valid in principle, as a proof that it can be done, making absolutely no assumptions as to whether there's any sense in doing it. I repeat, getting it right may be a genuine nightmare, involving huge amounts of trial and error, deleting the contents of %Windir%\Applog and letting Windows re-create it, finding conveniently long (>20-30 MB) executables and running them several times to make them jump to the top of Optlog.txt, then joining them together (you still know how to use the old DOS Copy command to accomplish that, right?) and renaming the file thus obtained to Win386.swp, and so on, and so on. It's essentially about tenacity: is a tiny bit faster swap file worth all that effort to you? But then again - you may be one of those lucky fellas that will get it right the very first time, who knows?
Now, about performance: what can you expect from an "optimized" swapfile? As a user who defragmented his swapfile, fixed its MinPagingFileSize - leaving out its MaxPagingFileSize altogether - to 128 MB (equaling the amount of installed RAM) and put it on the beginning of the hard drive, I would put it this way: at Windows startup, my sistem now "gets busy" ("hourglasses") for a second or two which wasn't the case before. I think it is because now Windows must allocate all that memory in excess - apparently, if you have, say, 128 MB of RAM, and tell Windows to use a 128 MB swapfile, Windows assumes you are going to use it all, so it allocates 128+128=256 MB of working memory instead of, say, allocating only the 128 MB of fast RAM, and putting aside the 128 MB of slow swapfile to use it later, if needed. Obviously, to allocate all that memory takes time... On the plus side, my sistem now rarely does that "rattle-rattle" (or "screechety-scratch", depending on your hard drive) routine it used to do regularly when resizing the swapfile. To be sure, when I use bloatware and exceed the fixed size, getting to 200-300 MB or more, the good ole "rattle-rattle" (or "screechety-scratch", depending on your hard drive) routine "routinely" reappears - only that, as a rule, it is not as noticeable when the swapfile gets enlarged - because this happens gradually, in smaller chunks - as when it gets shrunk back to its default 128 MB - since this gets done in one go when Windows decides that your system is "idle". That, in short, would be all. As for speed - on my system, I just can't tell whether Windows now runs any faster or not. It certainly gets its swap file resized less frequently - and that's about it. As for the perennial question - should I fix its maximum size or leave it to grow indefinitely like a cancer on my hard drive - I would put it this way: do fix it, if you feel like it. Then, test it a bit, run all the apps you usually do, and if your system still doesn't lock up, leave it fixed and just say a prayer or two every morning that this is not the day when eventually, it will lock up...
Don't feel like putting through all this tremendous work? Well, think about making use of a utility - there are not many - that will seamlessly do the work for you. The number one being, of course, Norton Utilities Speed Disk.