The Explorer: Resource Leaks, Part Two

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? Join in the discussion!

To discuss this column with other readers, please visit Fred Langa's forum on the Listening Post.

To find out more about Fred Langa, please visit his page on the Listening Post.