No. of Recommendations: 3
I don't doubt you jim but here are the numbers:

.............................Before ....After
Turbo says.................16% ...69%

Task Manager says.....20152... 90392

I don't notice a performance improvement but why the drastic change in numbers. I use win2k, 128M RAM?


I suppose these numbers refer, respectively, the percentage of physical RAM available, and the number of free megabytes of physical RAM available?

If so, then it doesn't mean much. What you would need to look at - especially in Win2K which (I think) has a fixed maximum size swapfile (that's how it is in NT) is the TOTAL amount of memory available - both physical RAM and swapfile.

I don't know exactly how memturbo does its thing, but the most common thing for such a utility to do is to request a block of memory that is larger in size than all the free memory in the system. The plan is to cause the OS to rearrange things in the system to free up a contiguous block of memory of the required size. This would require the system to write most of the contents of RAM out to the swapfile in order to make the space available.

The memory utility, having thus obtained the space, would then promptly free it (since it never planned to do anything with it anyway). At this point, your system would report all this available physical memory, just as you show here.

But what have you gained? Nothing. Because, due to the virtual environment, none of your applications know or care WHERE their memory really is. The OS handles all of that, using hash tables, and the performance of the memory manager is not affected by where in the physical address space a particular set of data is found.

In fact, you have not only not gained anything, you actually have lost a trivial amount of time. When the memory utility requested all that physical space, the system had to oblige it by writing out most of the contents of memory to the swapfile. Which took time. And when the apps who had that RAM want to run again, the system will have to swap the data back into RAM from the swapfile, which will take more time.

Some of these memory defraggers claim to be able to remove unused DLLs thus freeing their memory. This is a laugh. If you look through your list of active DLLs I think you will find that your utility has not succeeded in removing any unused DLLs from memory. This would be an almost impossible feat since the utility would have to search through all the task lists for every task and every DLL in order to find that a DLL was unused prior to unloading it. Given a virtual environment, and continuous context switches, the machine state will have changed considerably over the time that this search occurs. So even if the DLL was unused when the search started, it might be in use by the time the search ended. Hence, it could not be closed out.

These memory utilities claim to be able to free "orphaned" memory, lost due to memory leaks or crashed apps. Not true. The 32 bit Windows Virtual Memory Manager knows who owns what memory, and no one else does - and no one else can even find out since the system explicitly forbids it. The VMM will clean up properly after an exited or crashed task, restoring all allocated memory, and will explicitly forbid any other process from doing the same thing.

In principle, it might be possible for one of these utilities to free orphaned memory from an application that runs in the 16 bit subsystem, since this memory is not handled like the memory in the 32 bit environment, but in practice the utility can't do it. This is because the 16 bit subsystem does not keep track of which task "owns" the memory. It depends on the task to free all its own memory when it is done running. Should the task crash or otherwise fail to free its memory due to a programming error, that memory is lost to the system and cannot be recovered (in Win 95/98) short of a reboot. You can recover it in Win NT (and, I suppose, 2000) by killing the 16 bit subsystem (NTVDM), at which time the VMM cleans up the mess.

In order for a memory utility to free 16 bit memory, it would have to thunk into the 16 bit system, then access the private data structures of all running apps in the 16 bit system to find all the memory they had allocated, and compare those allocations to the list of all 16 bit memory allocated.

But note that I said "private data structures". Private structures are just that. Private. They are not documented outside the program, they may change from release to release, and they will not occur the same way in two different apps. So the memory utility would have to know the dirty details of EVERY 16 bit app that it might encounter in order to be able to search those private structures. What do you think the odds are of this? Slim or none?

Now, in the old days, prior to memory management and swapfiles, you could gain by using one of these devices. Memory would become fragmented and, lacking a virtual memory environment, you could get to the point where an app could not load and run because there were no chunks of contiguous free memory large enough to be allocated to permit it to load and run. In this kind of environment (which, by today's standards, is a primitive environment) a memory defragger was useful. But even then, orphaned memory could not be recovered unless the system not only kept track of what memory was allocated, but who had allocated it. In the early days, systems did not track who had allocated the memory. In those days, memory was at a premium, and no one wasted the resources keeping that kind of information.

And anyway, the bottom line is this - you said it yourself - "I don't notice a performance improvement..."
Print the post  


Live Video Event Monday!
The GP team is hosting a live video event on Monday at 4 p.m. ET. Don't worry if you can't make it — we'll have a replay and a transcript. Click for more!
When Life Gives You Lemons
We all have had hardships and made poor decisions. The important thing is how we respond and grow. Read the story of a Fool who started from nothing, and looks to gain everything.
Contact Us
Contact Customer Service and other Fool departments here.
Work for Fools?
Winner of the Washingtonian great places to work, and Glassdoor #1 Company to Work For 2015! Have access to all of TMF's online and email products for FREE, and be paid for your contributions to TMF! Click the link and start your Fool career.