myths.html

NAVIGATE		NOTABLE
index, stats root-main intro rules1 principles1 -- principles2 tweaks hints1 -- hints2 articles software1 -- software2 -- cmdline -- security links1 -- links2 sub-other config1 -- config2 glossary projects -- certs diverse -- screens events12 -- y-2007 -- y-2006 -- y-2005 about -- website -- rants sitemap	This page contains especially important articles written by me (most of them are exposing/debunking various PC-related myths), but it also contains other explanations/descriptions of, and information about general computing-related stuff. Similarly to the other pages on this site, the content is mostly personal (things that I've discovered myself and written about exclusively) and others that I've found browsing the Internet and reading them (i.e. the articles written by others; btw. for a few interesting webcoding related articles in particular, also see the "website.html" page), although note that for the non-personal ones, they at least contain modified text and are not just copied and pasted, i.e. they contain text that I wrote in my own words, however, the general point remains the same. For example on this "myths.html" page, all the articles are written by me, however, on the other "articles" pages, particularly for the "COMPUTER-IDENTIFICATION ON THE NET" one, I've got the general idea on some site when I browsed the Internet, but then I've added and removed few things, changed others etc., and actually, it's quite similar with "RUNNING A COMPUTER NON-STOP OR NOT" one, i.e. the part about "MTBF ratings" is not solely mine, and also with "THE MEMORY-FREEING PROGRAMS MYTH" one, i.e. the first part is modified text from the linked articles. But as mentioend, for all the others, I wrote them by myself entirely; but anyway, for one to write an article, one needs to get that knowledge somewhere, needs to get an idea somewhere, so in my opinion the "originality" of something is a bit relative thing. To say/summarize on the very beginning all that's further described below through the articles on this page in two short sentences: I have never ever seen an application or system crash because of so-called "low memory conditons". And futher, all this stuff that you hear about "registry cleaning" (if it would even work that way) would only be true if you would be running most of the time at 100% of RAM used (which is btw. a good, not a bad thing), so "slows downs" because of too much applications running (i.e. again, if they don't fill-up the entire RAM) is a completely non-existant thing.	label, license meta-stuff ---- ---- ---- legal-other ---- ---- ----

My various blogs: Here's a complete list of links to my various blogs; as first a link to my main Tadej: spletne objave [ add] blog on "Sopca" and my old Tadej na-liniji: razne objave blog on "VOLJAblok" portal, both in Slovenian language, as second there are the links to the two "ad revenue sharing community" blogs tayiper's blog [ add] on "Senserely", and tayiper's blog [ add] on "writingUp" in English language, then there are the three unsorted blogs satyr's diary on "Kuro5hin", satyr_moz blog [ add] on "Spread Firefox", and satyr's blog [ add] on "CastleCops" also in English language, and finally the three futile blogs tadej's journal on "Slashdot" (this one doesn't get much attention), tayiper's blog on "Techrepublic" (it's inaccessible to non-registered visitors), and the last one created tayi137's blog on "Yahoo360" (but also soon abandoned), all in English language too.

The contents of this site's pages are protected with a Copyscape.  
Copyscape site's mission is to offer a website plagiarism search and content copyright protection.

THE CACHE/DISABLE THE PAGEFILE MYTH

I've so far read various "Getting Rid of pagefile" related threads; for instance here is the latest one on "Ars Technica" forum Getting Rid of pagefile.sys:  http://episteme.arstechnica.com/groupee/forums/a/tpc/f/99609816/m/992004887731 (and there are numerous others dealing with this), and additionally I've also read the Caching pagefile increases performance 25-50% no joke. thread: http://forums.2cpu.com/showthread.php?t=10014 on 2CPU.com Discussion forums.

But this article/entry will also deal with "caching of the pagefile" (with help of SuperCache software for instance) and also with "placing the pagefile on RAM-drive/disk". You see, the main problem/question is: why go through the extra steps of having pages moved in and out of your working set or the modified list cache just to be moved to a memory pagefile. I mean why not rather use that extra memory for larger working sets and modified lists. If there is memory enough to host the pagefile in core, that memory is better served as directly accessable pages. Puting a pagefile in your cache simply adds another level of indirection which can be avoided by making that physical memory accessable to the OS for program/data storage rather than the cache. The simple fact is that placing the paging space in memory, whether by using a RAM-disk or this cache you have, is wrong. If there is memory enough to host the pagefile in core, that memory is better served as directly accessable pages. Puting a pagefile in your cache simply adds another level of indirection which can be avoided by making that physical memory accessable to the OS for program/data storage rather than the cache. It obviouslly doesn't make any logical sense. Cacheing the pagefile is really doing exactly what the OS is already doing with the modified and standby page lists. Windows does it much better actually; putting a page on the modified page list just involves unlinking it from one list, linking it to another, and updating maybe 12 bytes of other "bookkeeping" data; while "writing" it to a cached pagefile (or to a pagefile on a RAM-drive) takes a memory-to-memory copy. With all the bad effects on L1/L2 cache contents that that implies. (Now you've got TWO copies of the page in the L1 and L2 cache, while the second copy replacing 4K of other stuff that would have been better left in the cache. There's no real penalty from growing the pagefile or having it be fragmented. I/O to the pagefile is random anyway, and most of the pageable code in the OS tends not to get paged out once it's paged in. Demand paged virtual memory and merged VM/buffer cache mechanism is designed to efficiently satisfies applications with large appetites for memory.

So remember this: the cache takes RAM, and that memory allocated to the cache reduces the RAM available for process working sets. If anything a simple RAMdrive would be faster, since stuff written to the cached pagefile will still be written to the hard drive eventually, whereas the RAM-drive would leave it in the RAM allocated to the RAM-drive. So either way, it's still better to leave the RAM for the process working sets and so not incur the additional page faults at all. This only makes the IOs go faster, but why it wouldn't be better to not have to do the IOs in the first place. Now you might think "yeah, but those additional page faults will go faster than they otherwise would because they are satisfied in RAM". While this is true, it is still better to not incur them in the first place. And, you will also be increasing the page faults that have to be resolved to exes and dlls, and the pagefile in RAM won't do diddly to speed those up. But thanks to the pagefile in RAM, you'll have more of them. Also, the system is ALREADY cacheing pages in memory. Pages lost from working sets are not written out to disk immediately (or at all if they weren't modified), and even after being written out to disk, are not assigned to another process immediately. They're kept on the modified and standby page lists, respectively. The memory access behavior of most apps being what it is, you tend to access the same sets of pages over time... so if you access a page you lost from your working set recently, odds are its contents are still in memory, on one of those lists. So you don't have to go to disk for it.

Putting a pagefile in a RAM-drive is a self-evidently ridiculous idea in theory, and almost always a performance hit when tested under real-world workloads and actual measurement proves it to be a terrible idea in practice. You can't do this unless you have plenty of RAM. And if you have plenty of RAM, you aren't hitting your pagefile very often in the first place. On the other hand, if you don't have plenty of RAM, dedicating some of it to a RAM-drive will only increase your pagefault rate. Committing RAM to a RAM-disk and putting a pagefile on it makes fewer pages available for those lists, making that mechanism much less effective. And even for those pagefaults resolved to the RAMdisk pagefile, you are still having to go through the disk drivers. You don't have to for pagefaults resolved on the standby or modified lists. So just forget about it. But always do remeber the general "pagefile placement" related rule: Put the pagefile on the most-used partition of your least-used drive on your least-used IDE channel. The "most-used partition", because the head will be spending a lot of time there (if there are multiple partitions on the drive), while for the "least-used drive and channel", it's hopefully pretty obvious why.

THE PREFETCH-FOLDER CLEANING MYTH

As first, I you should really check the Ed Bott's: http://www.edbott.com article titled Windows Expertise: One more time: do not clean out your Prefetch folder!: http://www.edbott.com/weblog/archives/000743.html (note my own comments below under name "Ivan Tadej") and Popular Technology: CCleaner Cripples Application Load Times: http://poptech.blogspot.com/2005/10/ccleaner-cripples-application-load.html articles. As you can read in the Ed Boot's article linked above (and I guess also stated somewhere on the Microsoft's site too), the Windows cleans the old/obsolete files in Prefetch folder by itself (after 128 files were/are created); but anyway, why then to bother at all with doing the OS' job, i.e. to bother with deleting these files manually (or with 3th party program), I mean although it is true, that I was also used to delete at least those various "setup.exe-hash.pf" files that are remains/leftovers of setup/installation programs. I know now that that task was also completely unnecessary, since the Windows deletes the oldest files itself, when there are 128 prefetch files already created under Prefetch directory. So why on earth to make programs run/launch slower, even if only once??!

In fact, the only thing I do regarding the Prefetch folder is that I delete those various "setup.exe-hash.pf" files, i.e. the ones from few of my programs that gets updated frequently and so I use a different executable with the same name each time, i.e. on each installation/updating. Then I also delete .pf files of various temporary processes' files, although those are rarely created/run on my system. And finally I delete those orphaned .pf files from executables that I moved after the new .pf file was already created (with new file's location), however, I know that OS would delete them by itself after time, but I am a "maintenance maniac" and so I do it myself in certain cases. Then regarding what data that these files contain, I guess it's quite obvious that they don't "pre-load" anything (or whatever), they just contain a list of directories, OS-libraries that executable loads/maps/hooks on the execution (not sure which term is appropriate) and other non-OS libraries that are called or better dynamicly/delay-loaded during run-time by executable in question (I assume this because .pf files are created AFTER the respective process is closed and not ON or right after the execution) with regard to device, i.e. with regard to the hard-disk volume on which they reside, so it is only a some kind of map.

Also note, if Prefetching simply doesn't seem to work for you (i.e. Prefetch files NOT being created at all), the reason for this might be that you have probably disabled the "Task Scheduler" service; so to enable prefetching again just set it to Automatic startup-type. The other possibility is however that you've disabled the prefetching itself. Open the Regedit and check the value of "EnablePrefetcher" entry under the "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters" registry key.

Oh, and one note; this particular article of mine is more or less only a copied text from my comment in the Ed Bott's article's "comment section".

THE REGISTRY-CLEANING SOFTWARE MYTH

As far as registry "cleaning" programs being useless (and things that they do to your registry), I must say that I've always thought that this is not the case. However, I must note here on the beginning that two are actually two "major sorts" of registry cleaners. First, there are the ones that only clean (or should I rather say delete) any orphaned entries found during the registry-checking procedure; in other words, they are capable only of finding and then cleaning/deleting such orphaned entries. And as second, there are the others that beside finding these entries/values also search the hard-disk's drives for corrections of such entries; these are mostly the paths stored as values (i.e. files and folders), paths in values of other similar entries, or names of the entries themselves if they contain path-references. Anyway, the important thing here is that the registry is basically just a rather huge monolithic flat-file database which Windows loads into the main memory (i.e. RAM) every time the computer is booted (and operating system loaded), and keeps it in memory whilst Windows is running. Therefore lots of programs leave various "left-overs" (useless values) after uninstalling them. My opinion is (or better was, please read on) that is somehow clever to remove them, sooner rather than later. They are just taking additional space, and each additional bit that causes bigger registry means bigger registry file, and more time for system to find a particular entry/value), making the registry operations slower. Yes it is true, slower for 0.0000001 times, but slower anyway, and having left-overs from 20 or more uninstalled programs.

Well and then I was told on "Ars Technica" forum (thanks goes to a member/user with nick DriverGuru) that registry cleaning is rather useless... Yes, it surely might save some disk-space, but this is so small amount. And as the most important thing, please remember that as opposed to what various sites offerring these products say: the impact of so-called "registry cleaning" on any aspect of computer's performance is only a minor one (or yet better; there is no impact at all), mainly because the registry queries (reads and writes) are not linear, and also the registry is a demand-paged database (whatever that means, lol); in other words, registry cleaning doesn't impact the speed of registry operations (and therefore overall computer's speed) nomather how many of them were left after some program was un-installed, or how "deep" the respective key/entry/value resides in the registry structure. But especially removing unused/orphaned entires will not prevent operating system crashes, or so-called "registry or application conflicts" (because an application in most cases simply rewrites an old registry data i.e. a key, entry or value that's already there) and such. Uhm, on some sites they even state that "cleaning" the registry will prevent BSODs; well this is simply a big pile of bull-shit.

See various registry-cleaning related threads, first see the Registry cleaner thread on Winforums (my nick is satyr):  http://forums.winforums.org/showthread.php?p=33859, then a Suggestions For a Good Registry Cleaner thread on Wilderssecurity forums (my nick is stalker): http://www.wilderssecurity.com/showthread.php?p=260057 and finally threads posted on "Ars Technica" forum (my nick is shirker), and a special hint; look for the DriverGuru's posts, the guy really knows what he is talking about. The first one is removing unused registry entries? thread:  http://episteme.arstechnica.com/eve/ubb.x?a=tpc&s=50009562&f=99609816&m=397004907631, the second one Keeping the registry tidy - How DO you do it ?! thread:  http://episteme.arstechnica.com/eve/ubb.x?a=tpc&s=50009562&f=12009443&m=464007507631&r=123002707631,and the third one Registry Mechanic - Yay or Nay... thread:  http://episteme.arstechnica.com/groupee/forums/a/tpc/f/99609816/m/348008086731, however, I especially recommend you to check out the Registry junk windows fact of life article: http://www.sysinternals.com/blog/2005/10/registry-junk-windows-fact-of-life.html on Sysinternals site.

Of course you don't need special/additional software for that, one can simply delete them with Regedit, but it is much more comfortably this way. But if you just *must* use any of these "registry cleaning" programs, see the first two threads above for programs used to do the job. One very good and powerful is called Registry First Aid (or shortly: Reg 1 Aid): http://www.registry-first-aid.com, http://www.RoseCitySoftware.com/Reg1Aid from KsL Software and Published by RoseCitySoftware: http://www.RoseCitySoftware.com. I rather call this program a registry "maintainer" (an "editor" in a way) than registry cleanup application. The best is that doesn't "clean" registry automatically, but simply scans registry for orphaned invalid/orphaned data, and after that it then scans hard-disk for possible solutions, and offers the best one. You still need to decide by yourself. Sadly it is a SHAREWARE program, but anyway, it's so useful that it's worth paing for.

There is also another one that is pretty widely used. It is a FREEWARE program, called RegCleaner, or shortened to RegCleanr because of Microsoft's similar (or same, I forgot) name for some in-built application on 9x systems. It was developed by/under Macecraft Software (Macecraft Inc.), their main site is: http://www.jv16.org, while you get RegCleaner here: http://www.worldstart.com/weekly-download/archives/reg-cleaner4.3.htm.

Registry First Aid application is without any doubt crucial for me, as devoted user of "non-setup" applications, and devoted explorer of finding the optimal folder-structures, therefore moving things around a lot. For example hen I move some "non-setup" programs (or programs "group", like Players or Internet apps), it would be such a waste of time changing their paths in registry manually, or deleting them in few cases, i.e. in cases of application which do not overwrite an entry-value on next first execution, like ATM - Another Task Manager on my Win98, or old versions of Soulseek p2p client etc. But there are other cases also. For example when I changed my Program Files folder to just Programs, all the paths of various MS's software dlls, executables, data/config files etc. were suddenly wrong (and therefor Outlook not working etc.), and well, it was a matter of few clicks to fix them all in one pass. I rather not think about how it would look like, if I would try to fix them all manually. It is the word "cleanup" that is somehow wrong in my opinion for this kind of program, I would rather say that it is a "registry maintaining" or "registry fixing" programs , but only for the software capable of such operations.

/UPDATE: I need to refer you all also to the discussion in the Registry Cleaners thread:  http://episteme.arstechnica.com/eve/forums/a/tpc/f/99609816/m/488004770831 (see this post in particular: http://episteme.arstechnica.com/eve/forums/a/tpc/f/99609816/m/853006300931) on "Ars OpenForum" forum (my own nick there is "shirker"), where user with nick "PeterB" wrote about a little program that he made which creates a bunch of registry entries in various configurations, and then times some of the operations (i.e. opening keys, opening non-existent keys, querying values, and querying non-existent values) on those entries. Basically, gives a feel for how the performance of the registry is influenced by registry size, and clearly, the registry does not suffer any significant performance impact from being large. By the way, I also posted the Nesmiselnost uporabe registry cleaner-jev:  http://tadej.sopca.com/2008/02/12/nesmiselnost-uporabe-registry-cleaner-jev entry about this on my slovenian Sopca blog.

THE MEMORY-FREEING PROGRAMS MYTH

This article is trying to persuade you all who will read it, to not be led by sites offerring memory freeing/boosting/optimizing/defragmenting, ehm, even washing. As first, I urge you to check this article at Winnetmag site, written by Mark Russinovich (the co-author of Winternals/Sysinternals utilities) and titled The Memory-Optimization Hoax: http://www.winnetmag.com/Windows/Article/ArticleID/41095/41095.html, then as second the article written by Jeremy Collake (from Bitsum Technologies a.k.a Collake Software) called The Truth About Windows Memory Optimizers: http://www.bitsum.com/winmemboost.htm, then third the Fred Langa's article at InformationWeek with a title The Explorer: Resource Leaks, Part Two > June 5, 2000: http://www.informationweek.com/story/showArticle.jhtml?articleID=17200583, the entry titled RAM Optimizers/Defragmenters on Mywebpages-SupportCD website, the "XP Myths" page: http://mywebpages.comcast.net/SupportCD/XPMyths.html, and finally the article at Aumha site by Alex Nichol titled Virtual Memory in Windows XP: http://aumha.org/win5/a/xpvm.htm. You see, the general bottom-line is that you want your RAM to be at full load more or less all of the time (i.e. the RAM "space" to be as used as possible; in terms of allocated addresses holding the "real" data), so remember: free RAM is a wasted one.

A few words on how Windows manages virtual memory. With modern computing, the worst thing you one can do for computer's performance is to touch the hard drive or in fact touch any non-memory storage. The fastest hard drives on earth are still slow compared to the computer's main memory (i.e. RAM), so you see, even with the "solid state" drives, in order to access the drive, one has to jump into system code and drivers, and this will push your own program's code out of the CPU's L2 cache (this is btw. called a "locality loss"), while there are two typical reasons one has to touch the disk. The first reason is when the application requests it explicitly (Word asks Windows to load "somefile.doc" file into the main memory), and the other is a so-called "hard fault", which occurs when the application tries to use memory that has been paged out to disk via "virtual memory" and needs to be paged back in. The principle is quite simple, i.e. Windows tries to keep commonly used pages of data in RAM, while less commonly used ones in the pagefile. So if on a given moment there is no RAM available, then pages not currently in use (i.e not actively used, since they might be used in near future) are moved to the pagefile. For this task it uses various lists; a so-called "stand by" list, and a "recently used" list. The process of moving a page of memory from RAM to the pagefile is calling "paging-out". So because these "optimizer programs" force the available memory counter up, the documents opened after this so-called "optimization" (the code that was part of processes' working set before the "optimization processes", i.e. present in the physical memory), must be re-read from the hard-disk when one continues to edit the document or open anopther instance of already running process. Thus it only slows-down the overall performance and responsiveness. On this point, I urge you to read the five DriverGuru's posts (posted one after another) on Ars Technica. The topic-tile is Where'd my free memory go?, and here is a link pointing to the first one out of five posts:  http://episteme.arstechnica.com/eve/ubb.x/a/tpc/f/99609816/m/2590999945/r/2870972055#2870972055. Conversely, the process of pushing a page of memory from the page file to RAM is called "paging-in". So virtual memory is limited only by the size of the page file plus the size of all the RAM sticks' capacities, i.e. the system can use gigabytes of memory even if the RAM is only a few hundred megabytes. And these programs do basically the same thing; they free up physical RAM (that would be used otherwise), and they do this simply by forcing as much possible allocated pages in physical RAM into the pagefile (or they allocate it to itself). Therefore the amount of free RAM is increased (why would anyone in the world want that??), but the amount of virtual memory in use is not affected, i.e. there is no increase in free memory, only the increase of free RAM. When the applications whose memory was put into the page file become active again, the pages of memory they use must be loaded back into RAM, incurring substantial overhead and causes performance degradation.

Strictly my opinion, things that I've discovered:

I must say that I agree 100% with the articles I linked above. You see, I have tried various different programs of the mentioned kind (on the beginning of my "geek" era), and have actually used some of them in past on both, my Windows 98/SE and Windows XP setup. I've tried to use the ones that were not bloated with additional useless features, and generally looked somehow more or less "promising"), and soon I discovered most of the things that Mark mentioned in his article. Freeing up memory (paging it out to pagefile, btw., do not confuse pagefile concept with Memory Mapped Files), that would be used otherwise can only lead to performance degradation.

1. Why to "free" RAM as many of these programs offers (it's actually page the data out to hard-disk), when more that 10, 20, or 30% of RAM are still available, not allocated? Because if doing so, the system logically becomes much slower for quite some time (obviously slower), till all the used data (the data that were meant to be in RAM) are paged-in back to RAM.

2. Why to run an additional process to do exactly the same job as Windows Memory Management does. In other words, why to run an additional process if Windows itself manages paging in/out data sufficiently, but especially when the RAM is almost full (and of couse in other cases), so the "Free RAM, when only 5% is free" feature offered by some of those programs is completely and 100% useless.

3. There is no such thing regarding the memory management as: "This software will prevent crashes, freezes, lockups, BSODs (hehe), and generally improve the stability and performance of your computer". These programs are rather actually causing the problems (crashes, freezes or at least a delays and sluggishness) during the procedure of "freeing the RAM".

4. I suppose that there is nothing like "freeing/clearing RAM" as it says on many homesites of these programs in the meaning that some amount of data is in RAM, and after this "optimizing process" this data is freed; not in the meaning of being paged-out from RAM to pagefile, but "freed" in the meaning of being cleared (the portion of RAM that was previously allocated to the programs but it's not used anymore), so no more allocated nor in RAM nor in pagefile, i.e. simply vanished. Well, I imagine this might actually happen in certain situations, for instance in cases of so-called "memory leaks" caused by programs that don't perform well the job of clearing the old data from RAM (garbage collecting)

Although on the other hand, I could partially agree with forcing the data to be paged-out to disk, but only on 9x systems. I assume this could be useful for gamers, or hogging music and graphic programs users etc. Like for example after being on internet (when lots of processes and IE instances were opened), and after disconnecting and closing all those processes, to additionally attend to "clean" so-called leaks (see above) because I suppose Windows 9x platforms have/had completely different Memory Management compare to Windows NT systems. However, the main question that remains for Windows 9x platforms - is really all RAM freed after user closes the process that allocated it on execution (or later when working with it, so same as on NT systems, or there could be some section/area that could be called "wasted" and therefore needed to be manually freed and I mean freed and not paged-out to pagefile, since uhm, the programs that was using this portion of RAM was closed, so there is no other programs that would use this memory instead (we are not talking about shared dlls and MMF in this case)

Disclaimer 1: The opinions expressed on my website and in my files are mine, or belong to other individuals/entities where so specified. Each product or service is the trademark of their respective company. All the registered copyrights and trademarks (© and ™) referred in this site retain the property of their respective owners. All information is provided as opinions only. Please, also see the "Disclaimer 2" on the page "about.html".

All the pages on this website are labeled with the ICRA label.  
The website is maintained solely by its author and is best viewed with a standards-compliant browser.