SPECIAL EXTENDED COVERAGE!

After writing Part One of this series on Resource Leaks, I've been hip-deep in various software tools that claim to recover "leaked" system resources, or to prevent leaks in the first place. [If you haven’t seen Part One, or if it’s not fresh in your mind, please check it out as it contains information that’s essential for understanding what in this column.]

In the last two weeks, I’ve tested more than a dozen of these tools and utilities on carefully-configured test machines. Furthermore I tested the software that showed the most promise on my daily-use PC, for an additional real-world flavor. In each case, I've carefully monitored the results. This special, extended-coverage column details what I’ve found:

One Approach: AntiCrash

AntiCrash is a freeware Java applet that purports to enforce proper multithreading in Windows and to prevent resource leaks: “Prevents Windows from crashing....It loads on your Windows desktop and… provides a true multi-threading environment…[A]pplications can be opened and closed without the system getting unstable or slow.”

I love the name -- and the concept. An add-on applet that keeps Windows from crashing? One that actually prevents crash-resultant memory leaks in the first place, rather than trying to clean them up afterwards? Lemme at it!

Alas, just as with every other crash-proofing tool I’ve ever tried, AntiCrash doesn’t live up to its name. I actually had more and worse stability problems with it running than without. I even had one out-of-resources crash I can directly attribute to AntiCrash. Worse, the documentation is badly written and nearly devoid of any useful information so you’re left with no clue as to how the app actually does what it tries to do. (I get very suspicious about low-level apps that want to insinuate themselves deep into the guts of my system, but don’t tell me what they’re doing, or why, or how.)

Some readers report good results with AntiCrash, and some popular download sites recommended it. But I have to believe there’s a placebo effect at work, and that people are seeing what they want to see -- they’re seeing results that just aren’t there. My tests were as careful as any I’ve done in 20+ years of software testing, and the only clear effects I can attribute to AntiCrash are negative ones. As is usually the case with simple fixes to complex problems, Anticrash is simply inadequate.

In short: Don’t waste your time.

The Most Popular Approach: Memory Optimizers

On the surface, “memory optimizers” are a far more rational approach to solving resource leaks. Your system’s pool of total available memory is a combination of two kinds of RAM (random access memory): actual physical memory chips, and a reserved area of hard disk space called “virtual memory.” Although virtual memory is a kind of RAM, in order to avoid confusion, when I refer to RAM in the rest of this article, I’ll mean the RAM provided by memory chips.

On its own, Windows lets your RAM fill up, as it should, because that’s what it’s there for: For the most part, you want the stuff you’re working on to be in RAM because that’s the fastest, most-responsive memory you have.

But when you load more apps and data than your RAM can hold, Windows makes judgments about what’s important and what’s not -- and what’s likely to be needed again soon, and what’s not. Windows then writes some of the less-vital contents of RAM to disk in the virtual memory area. When something’s needed from the virtual memory area, Windows loads it back into RAM, making room (if need be) by swapping something else out of RAM onto the disk. It works pretty well, but (of course) isn’t perfect. That’s where “memory optimizers” come in.

There are differences among the various optimizers, but a typical memory optimizer is a small utility with one major trick up its sleeves: It can pretend to be much bigger than it really is. When it runs, the optimizer monitors how much of your physical RAM is in use. When your RAM is almost all in use, the memory optimizer pretends that it’s a huge app needing 20MB or more of RAM. (You can usually adjust how much RAM you want the optimizer to pretend to need.) Windows thinks a huge new application is coming aboard, and obligingly makes room for it by writing, say, 20MB of something else out to disk. The memory optimizer then goes back to its real size, leaving you with a nice, fat “hole” in your RAM: This RAM is ready to be used by whatever app you load or use next.

Some memory optimizers also “defragment” the rest of your physical memory, moving memory chunks around so that the available, unused RAM is all in one chunk. Along the way, many of these optimizers claim to recover leaked memory as part of the defragging process.

Combined, opening the hole in RAM and defragmenting the rest of your active memory are supposed to give you a “just booted” feeling, making your PC faster, more responsive, and more stable.

Problem #1: Resource Losses

Memory optimizers operate on your pool of general memory. They have nothing whatsoever to do with the fixed-size User and GDI memory areas that are the real problem with resource memory leaks.

So let me be clear: These memory optimizers DO NOT and CANNOT do anything at all about true low resource problems. If you have a leak that's causing low resources in your GDI or User areas, it won’t matter if you shuffle code and data from RAM to disk and back all day. No amount of opening “holes” in RAM will do anything at all to restore lost GDI or User resources.

Right now, there are probably readers saying, “Fred, you’re all wet!” because some folks swear by memory optimizers. Here’s a snippet from an actual e-mail I got last week -- one of many similar such messages:

"Fred, [name of utility] saves my butt -- I get my resources down to 5 percent and then it kicks in and restores them to 50 percent..."

But invariably, when I check out whatever tool the reader thinks is recovering resources, I discover it’s working on his or her pool of system RAM, and not "System Resources" in the normal sense of User and GDI. The confusion is understandable because of the way the, um, less polished memory optimizers toss around the term "System Resources" to make it sound like they attack the much more serious problem of User and GDI leaks. Again: They do not.

In fact, the better memory-management tools explicitly state that they do nothing -- nada, zip, zero, zilch -- about User and GDI Resources or any memory leaks therein. These apps may help with a completely different and less significant kind of memory leak (that's a huge qualifier; we’ll come back to this later), but that's a separate issue that has nothing to do with true System Resource leaks in the User and GDI areas.

Ironically, the only effect these tools have on User and GDI is negative: Because a memory optimizer is itself a Windows application, running it consumes at least a few percent of your GDI and User resources. You can prove this to yourself using either of the two methods discussed in the previous column. Run, say, Resource Meter, and then run your memory optimizer. When you load the optimizer, you’ll see GDI or User resources decline. Now make all the “holes” in RAM you want: You won’t see any improvement in User or GDI.

In short: If your problem is low system resources, running a memory optimizer will actually make the problem worse, not better!

Problem #2: Speed Losses

RAM operates at nanosecond speeds, but your hard drive operates at millisecond speeds, an enormous six orders of magnitude slower. When memory optimizers run, they’re forcing code and data out of the near-lightspeed realm of RAM onto a relatively slow mechanical hard drive.

This takes time; when these apps kick in and request a huge chunk of RAM, Windows stops, figures out what should be moved, and then performs the disk write. This can cause a very noticeable stutter -- or even a delay lasting several seconds -- in running your apps.

Worse, as that just-moved code or data is needed again, it will be read right back into RAM from the hard drive, causing another delay.

I can’t think of any scenario where having a “hole in RAM” would make ordinary, routine Windows operations faster. Quite the contrary, for routine running, all the memory-shuffling caused by these memory optimizers ends up costing you more time -- lots more time, because of that gigantic six-orders-of-magnitude speed difference -- than any possible speed benefit you might gain thereafter, including any speed gains from “RAM defragmentation.” I’ll cover that in the next item:

Problem #3: Meaningless Gains

When many of these optimizers try to “defragment” the rest of your RAM after they’ve opened a hole, you’ll experience yet another noticeable delay as the memory in live RAM is shuffled around.

But isn’t defragmentation worthwhile anyway? After all, defragging a hard drive is generally regarded as a good thing, so wouldn’t defragged RAM also be good?

Here’s why I say no: Let’s say you want to load an application, and that defragging your hard drive lets you avoid 100 unnecessary repositionings of your drive’s mechanical “heads,” saving 10ms each time. That saves you 1000ms -- a full second -- which is an easily perceptible amount of time. Over the course of a day, a defragged PC indeed will feel noticeably faster than one that’s not defragged.

Now let’s look at loading an app from defragged RAM, bearing in mind the speed difference between RAM and hard drives: If defragmented RAM lets you avoid, say, 100 memory-access operations at 60ns each, you’ve saved 6000ns, or -- gosh! -- a whole six millionths of a second. To say that is too small to notice is beyond understatement. It's so small, it's irrelevant.

As far as I could see in my tests, any possible speed gains provided by these optimizers is more than offset by the time they take to run: By the time you’re done, it’s taken you longer to run with these optimizers than without.

But Wait: There Are Benefits

In fairness to memory optimizers, I can think of three ways that they might help at least a little: First, some optimizers claim to use special, heavy-duty versions of memory-allocation routines that were originally intended for use by software developers. These are more aggressive than Windows' standard-issue memory allocation routines and can potentially overcome some problems with misallocated general memory.

After an application crashes, for example, it’s possible for some general memory to be “orphaned” or marked as still in use, when it actually is not. And some apps do leak small amounts of general memory -- that is, they don’t properly clean up after themselves. In these cases, and in instances where Win98 can’t recover the leaked general memory on its own, running a memory optimizer may be able to recover the leaked memory.

But note that this still has nothing to do with User and GDI Resources. What’s more, because your total pool of memory is your RAM and virtual memory combined -- an amount that can be hundreds to thousands of megabytes -- minor memory losses here simply aren’t the big deal they are in the extremely limited, kilobyte-scale confines of the GDI and User space.

So, yes, a memory optimizer may be a minor help -- but it’s certainly not going to change your life in any radical way.

Benefit #2

Although many of the optimizers work automatically (triggered when available RAM falls below a preset level) most also contain instructions that say something like: “Before you run a humongous application, manually trigger the optimizer again and again until you’ve opened up enough RAM for the new app to fit in. Once the optimizer is finished, you then launch your app, and Windows can read the app into the new hole in RAM.”

Normally, without the optimizer, Windows would start to load and run the app, simultaneously calculating how much of what kind of RAM (physical or virtual) is needed, moving chunks of code and data in and out of virtual memory as needed, and so on. But if you follow the optimizer’s instructions, you stop working to trigger the optimizer; then while you wait, Windows does all the housekeeping it otherwise would have to do on the fly as the new app loaded and started to run. Because you’ve reduced the workload on Windows, I can imagine how this might sometimes improve stability in some systems -- albeit at a very high cost in lost performance.

And I can imagine that some CPU-intensive games may also benefit from getting all the disk swapping out of the way before the game runs, rather than slowing things down later, when you’re up to your armpits in alien attackers, or whatever.

But please note that I meant it when I said, “I can imagine” these possible benefits. I never actually saw any such benefits during my tests, and in fact, my systems multitask and disk-swap just fine, thank you, without the optimizers. I’m just trying to be scrupulously fair by theorizing about any possible marginal benefits these optimizers might yield to some users.

Benefit #3

By forcing Windows to open up a large chunk of RAM, a lot of data -- typically tens of megabytes -- will get written to virtual memory. As that code or data is needed again, it will be read right back into RAM. Thus, aggressive use of a RAM optimizer can help ensure that your RAM contains only the freshest, most-often needed data and code. In fact, I think this accounts for the “freshly-booted feeling” many of these optimizers claim to provide.

But once more, all this comes at a very real cost in time. (See Problem #2, above.) All the optimizers introduce a very noticeable delay when they go to work; and even more so if you stop work to trigger them manually. If a “freshly booted feeling” is worth that kind of delay to you, fine. For me, when I want “that freshly-booted feeling,” I’ll just reboot and be done with it. Not only will a reboot completely clean up RAM problems, but it also will recover leaked memory in the User and GDI areas -- something none of the memory optimizers can do.

One Use That May Make Sense

I can think of no good reason to keep any of these apps running on your system all the time. In all my tests, at best they took more than they gave; at worse they made my systems slower and less stable.

But I can think of one instance where it might be useful to have a memory optimizer on hand for occasional manual use: It’s benefit #1 mentioned above -- the ability to recover memory orphaned after an applications crash.

The freeware RAMpage memory optimizer, RAMpage, for example, has a command-line-driven “run once then exit” mode. I’ve coded the command-line parameters into a batch file, and I now run RAMpage after some other application crashes: RAMpage loads, opens up a hole in RAM, tries to recover “orphaned” memory left by the crashed app, defrags what’s left, and then exits. I’d never leave RAMpage (or any memory optimizer) running all the time due to the problems listed above, and because of the relative rarity of applications crashes. But as a simple, free way to try to clean up after an app does crash (and thus possibly avoiding the need to reboot) it seems to work pretty well.

In fact, after some tinkering, I’ve developed a four-part strategy that gives me great results: I’m able to prevent most memory- and resource-related crashes in the first place, and can skate into the single digit range of User or GDI resources without any trouble at all. And when an app does die for some reason, I can now recover orphaned general memory without rebooting, using RAMpage. In my tests, I've gone day after day after day with my resources rock-steady and stable.

The strategy involves several approaches, including optimizing all Windows memory areas -- the swapfile, Vcache, and so on. I’m putting the final touches on the four-part plan now, and will present it in detail in the next installment of this series. Stay tuned!

Meanwhile, do your experiences with memory optimizers parallel mine? Or have you found that they really do help with resource leaks in some measurable, quantifiable way? Are the tradeoffs mentioned above worthwhile to you, and if so, why? Have you found tools that let you directly adjust User and GDI? (I haven’t found any.) What ways have you found to employ optimizers, and which are your favorites?