Memory Trimmer

[streetfighter 2]

Currently I'm writing a robust system control application which includes a memory trimming/cache flush feature which I thought would make a nice standalone app. I designed my standalone trim/flush tool off of the program found here:
http://www.koshyjohn.com/software/memclean/

Anyway, onto my program...

Memory Trimmer v1.0 Beta
Compatibility: 64-bit Windows Vista/7
Name: mem_trim_x64.exe
Size: 258KB
Version: 1.0 Beta
Date: 1/23/2011 (or 23/1/2011 if you're not from the USA )

If you want an x86 version look here.

What it do?
Memory Trimmer allows you to very easily clean the working set memory of applications in addition to clearing the system file cache. In order to accomplish this the program uses two APIs:

[URL="http://msdn.microsoft.com/en-us/library/aa965240(v=vs.85).aspx"]SetSystemFileCacheSize[/URL]  - Clears the file system cache when given args (-1, -1, 0)
[URL="http://msdn.microsoft.com/en-us/library/ms686234(v=vs.85).aspx"]SetProcessWorkingSetSize[/URL] - Cleans the working set of a given process

Memory Trimmer does require administrative privileges. Nevertheless I do not believe that this program presents any risk to corrupting memory as these functions are called by Windows and it's applications quite regularly.

So why use it?
Dunno. I'm sure if TheMailMan78 reads this he'll say this is stupid and people who use this are the kind of people who disable the Distributed Link Tracking client . At worst Memory Trimmer will cause any programs running in the background to draw very slowly when you try to open them (or change their state). At best it helps free up RAM for programs with built-in memory managers (that don't request extra RAM from the OS). Either way I would consider this an advanced tool by virtue of it's limited applications. I wouldn't recommend anyone use it. Fortunately for me I'm not anyone .

How to use it?
Since this is advertised as an advanced tool I'm only going to provide limited instructions. If you run the program with "/h" argument you'll see this:

Memory Trimmer has switches ! If all you want is to flush the cache and trim working sets, simply create a shortcut to Memory Trimmer with the following arguments, "/f /t /n". If you'd like to trigger a flush and/or trim operation when you start a particular program you can use the "/r" switch. The Memory Trimmer interface provides a method of creating shortcuts which launch applications which you can see here:

You can drag-n-drop or use the Open button to select the file you want to create a shortcut to. Then check "Trim" and/or "Flush" and click "Create Auto Trim/Flush Shortcut". If everything went OK, a shortcut will be placed on your desktop. When you launch the shortcut don't be surprised if Memory Trimmer doesn't show up; that's because the shortcuts Memory Trimmer creates have the no-GUI switch ("/n") enabled. Memory Trimmer will Flush/Trim then launch the program you specified.
You can also change the poll rate of the memory usage info.

What about the source?
Like all of my apps, Memory Trimmer is open source . It is written in win32 C++ and compiled with MinGW-w64 (an open source compiler). Furthermore, it was written using notepad++ (an open source text editor).
The code is heavily commented and provides two batch files which automate the build. Assuming you have MinGW-w64 in PATH, you can compile Memory Trimmer simply by running either batch file. The batch file "build64.bat" compiles using ANSI and "build64_unicode.bat" compiles using UNICODE. For whatever reason the ANSI-compiled executable had to be run in compatibility mode on my Windows 7 VM, but worked fine on my actual computer. Consequently the binary I'm releasing is the UNICODE version. Memory Trimmer also uses Common Controls 6.0 and requires Administrative privileges.

Where's the compatibility?
I made an x86 version, though it's not quite as good as it's x64 sibling.

Bug reporting
Reporting a unique bug (one that someone else didn't already mention) will be greatly appreciated (and thanked) by me.

 

[ChiSox]

Nice work...I'll throw this on when I bench so I can clean up when switching programs.

Also your thread presentation is clean, much respect.

 

[streetfighter 2]

Memory Trimmer v1.1 Beta for x86
Compatibility: Windows XP SP2/Vista/7
Name: mem_trim_x86.exe
Size: 238KB
Version: 1.1 Beta
Date: 1/25/2011 (or 25/1/2011 if you're not from the USA )

What it do?
Like the x64 version, Memory Trimmer cleans the working set and flushes the system file cache with an easy to use interface. The main difference is that when launched on XP, Memory Trimmer will use _flushall() instead of SetSystemFileCacheSize(). I'm not sure if it really accomplishes the same thing, but it's the best I have right now.

So why use it?
Read about it here.

How to use it?
Read about it here.

What about the source?
Though the x86 and x64 versions have a very high commonality there are some major differences. The x86 version includes functions that provide better support for Windows XP themes (and also for the lack of themes). It is also important to note that Memory Trimmer x86 cannot be compiled using standard MinGW. Memory Trimmer uses the shobjidl.h header which is not included in the regular MinGW compiler so you must use the 32-bit version of MinGW-w64. Another issue is that SetSystemFileCacheSize() is defined but not implemented on the 32-bit version of MinGW-w64 so the function has to be called using explicit linking to kernel32.dll.

This is actually my first program using Common Control tabs, and I'm aware that I did a pretty nasty job of it. I wasn't able to find a good clean example of tabs until recently so I plan to rewrite the tab section of the interface when I get around to it. Compatibility should increase substantially when the new interface is completed.

Known Bugs
-When changing themes in XP, Memory Trimmer must be restarted or it won't display correctly.
-In XP shortcut creation does not appear to work, despite Memory Trimmer reporting success
-The call to CommandLineToArgv() in WinMain() occasionally prevents Memory Trimmer from starting, usually with the error "this program quit abnormally" or the program freezes at 100% CPU.

Changelog

1/25/2010:
-new version 1.1!
-added ExplicitSetSystemFileCacheSize and OS detection so that the best cache flush method is used in each OS

 

[Kreij]

Hmmm ... clearing the working set of a process will cause it to start generating page faults when it goes looking for those pages, no? (unless the page is used by multiple process, in which case it still keeps it in RAM anyway unless it is removed from all processes)
Not a bad thing, but isn't the working set there for a good reason? (to prevent page faults from occuring)
I do understand that a coder can over-estimate the needed size of the working set and leave a bunch crap in memory, but page faults will definitely slow things down.

How about another tab in the program that shows the size of the working sets for the processes, and then allow clearing of working sets for specific process?

Yeah ... I'm a trouble maker.

 

[streetfighter 2]

Hmmm ... clearing the working set of a process will cause it to start generating page faults when it goes looking for those pages, no? (unless the page is used by multiple process, in which case it still keeps it in RAM anyway unless it is removed from all processes)
Not a bad thing, but isn't the working set there for a good reason? (to prevent page faults from occuring)
I do understand that a coder can over-estimate the needed size of the working set and leave a bunch crap in memory, but page faults will definitely slow things down.

How about another tab in the program that shows the size of the working sets for the processes, and then allow clearing of working sets for specific process?

Yeah ... I'm a trouble maker.

No, you're not a trouble maker-- Err, well maybe you are, but your post isn't much of a precedent .

I probably should have called the current version "alpha" instead of "beta" because I plan on adding more monitoring features and a third tab which allows the user to trim/flush on an interval or when the cache/working set exceeds a certain size. The benefit of having an interval/limit cache flush is useful with programs that are injured by excessive caching (SQL server comes to mind). I can't think of a reason why anyone would want an interval/limit working set trimmer though, but why not?

I'm developing another app which will have per process control options (like you described). I'm still undecided on whether I should implement that feature in Memory Trimmer. Currently I'm rewriting the interface to better utilize tabs and when I'm done I'll be considering what features to add.

Also I just figured out that I'm an idiot . The SetSystemCacheFileSize() API is available in newer 32-bit OSes, it just isn't available in XP (except XP x64). Consequently I'm going to change the x86 version of Memory Trimmer to utilize SetSystemCacheFileSize() on supported OSes, and use _flushall() on XP.

Trimming the working sets will definitely cause more page faults, but it principally injures programs that are currently running (when relative to programs with impending startup). I'm pretty sure even in C# (by default) the working set of a process is trimmed when the program is minimized. The idea is if you want to launch a program that can utilize a lot of memory, and doesn't depend on too many background services, you can trim all the working sets and have more memory available to the program when it's launched (and begins allocation). Most programs will request more memory from Windows (if needed) and Windows will then perform the trimming. Unfortunately some programs seem to resort to excessive paging instead of trimming background processes.

I should point out that this is really just my theory. I'm reading about memory management in Windows 7, but I don't have a working knowledge at this point and time.

 

[ctrain]

I think you may only be damaging performance in doing this, you're pushing stuff out of memory and to disk. Following what the task manager says is not a good idea if you're at what it reports for memory usage.

Generally best to just let Windows handle itself.

 

[Kreij]

No, SF2 is correct in that if you remove unneeded working set of programs that are idle a lot you will get more memory back for other things if you need it. You should only see performance degredation if you smoke a working set that gets used on a regular basis.
Some programs are writtten to use stupidly large working sets, or the garbage collection of the app is weak.
You just need to be aware of what you are doing. As he said ... advanced tool.

 

[ctrain]

The difference is that the OS monitors patterns of usage in memory and knows how to move things in and out accordingly, you can't mimic this, so you may end needing a page you effectively just pushed out and get to eat a page fault.

A fun experiment maybe, but arguably snake oil in reality.