You had fun typing that didnt you? lol
You are new here. My posts are typically rather long. Don't let it go to your head though.
Ok lets cover a few things, then it ends here as I wont be dragged into another fight over this and another person who is dead set in their view. After this post I wont be posting again.
Ok, you know, I really don't like when people do this. If you aren't going to get into an argument, which you already said in your previous post, why the *censored* are you doing exactly that right now?
You said you read the about page, sounds like you read it a little to fast. CleanMem doesn't fill the memory like the old crap clears did. It doesn't change any programs working set or change any program or inject anything in any way.
Don't be silly. By that same metric one could argue that no common desktop application actually opens files, it get's windows to do it. Of course your program isn't doing it, but it is doing it by proxy of having the instructions that make it happen. Of course no other tool does this itself, either; most of them just use a few of the Process-related API calls. the only reason I (or anybody) cannot see the actual functions in use in your program is because VB6 performs all DLL calls dynamically via DLLFunctionCall() in the runtime, but given the tests I just ran I'm pretty confident it doesn't actually do anything, at least with regard ot it's cleaning functionality- that set's it apart from the other common memory cleaners.
Cleanmem simply calls Windows to cleanup any unused memory from a process
The function I find that make those changes are things like SetProcessWorkingSetSize, SetProcessWorkingSetSizeEx, FlushProcessWriteBuffers, or ntSetInformationProcess. It might also simply use
EmptyWorkingSet(), as well. (or MmAdjustWorkingSetSize(), but the result is much the same).
I'm fairly confident, however, that it probably uses either EmptyWorkingSet(), SetProcessWorkingSetSize(), or SetProcessWorkingSetSizeEx(),which is sort of evident in the quick tests I did- the only value that consistently reduced by a rather large factor was the Working Set Size of each Process. The test found absolutely no discernable difference speed between before and after them (well that's not true, the game test ran 1 fps slower after running it but that's within a safe margin of error). Of course this was on a system with 8GB of RAM, I intend to repeat the tests with less memory and see if the impact is more positive.
Windows does all the work, not cleanmem. Windows moves the memory into the system cache, which is STILL in memory, NOT the page file. A process will have back what it needs instantly. Any memory not called back will be left in the system cache for a short period before it is released.
The observed behaviour I saw after running the program was a universal reduction in the Working Set of all Processes, in many cases by half. Those memory pages do not get deallocated, but simply removed from the process working set. But when that page is accessed again, either a hard fault occurs (and requires access to the pagefile) or a soft page fault occurs, because the data can be accessed without using the backing store. This occurs if the page is in the working set of some other process, the page is in transition, because it either has been removed from the working set of all processes that were using the page and has not yet been repurposed, (I believe the cumulative "transitory" pages might constitute what is often referred to as a System Cache on XP and earlier).
I'm still unclear how this would increase performance. Aside from there being a larger amount next to indications of the amount of free Physical memory (because transitory pages count as Free).
I was notified of these posts simply for the fact of the bashing of my program without any proper tests and the bashing of the fact that I used VB6.
I didn't bash it explicitly. All I said was "in VB6 no less" which another poster detrimented further. Visual Basic 6 was a fine programming language and environment in the mid 90's. The problem today (and one of the reasons I moved away from it) is that I found myself fighting language limitations more than I found myself using language capabilities to my advantage. (Implementing IEnumVariant, Multithreading and concurrency, iterators, supporting modern UI themes and 32-bit application and window icons, etc). If a smaller, simpler program doesn't run into those limitations, I don't see a problem. (And even when you do, enterprising developers have usually trodden that ground). VBAccelerator.com is still in my bookmark bar, even.
Somebody needs to also hurt whomever decided that the Version 6 common controls would not be actual Windows Common controls, thus preventing the use of functions from comctl32.dll for things like drag images.
Sorry if I am a *censored* good programmer in VB6 and it still works fine. Guess it isn't up to your standards.
Nonsense. I've written blog posts and programs in it myself. And your reasons for choosing it are perfectly reasonable. Especially for something as basic (no pun intended) as this sort of program, since most of the work (and appeal) I would argue is best found in the monitor tool, which if we set aside the differences on the actual "cleaning" functionality and it's capabilities can be useful in and of themselves, which could very well be part of the reason you decided to make the enhanced version a nicer version of that part of the program. Additionally, as a monitor tool it benefits from the overall lightness of VB6 in comparison to say a .NET application, since they (like yours does) will often start with Windows or on a schedule, and as a background application it's always best to be as light as possible. That said, from a language capability point of view, Visual Basic 6 doesn't really have a lot going for it, particularly compared to more modern programming languages. With the possible exception of Java, which is about equivalent to VB6 in capability despite how loudly I'm sure Java programmers would protest.
After all, 2 million machines using it and people who tested it giving it great reviews I am sure I wont lose sleep over more people not trying it shooting it down.
Ad populum fallacy but I think you know that. My praise would lie entirely on the graphical portion of the program, such as the RAMpage like Notification Icon. I guess my real problem comes from the name, since a lot of these programs really do emphasize how they happen to call a few APIs for trimming working sets, but seem to put, marketing wise, their awesome Memory and statistics views on a back-burner. I Ran RAMpage for years after deciding it was actually far less useful in terms of it's attempts to free memory, simply so I could keep track of Physical Memory usage. Though how useful knowing that is, is probably also debatable...
CleanMem has been out for years now and I had to do this fight so many times. Each and every single time it was with people set in their ways, calling snake oil without even testing it.
I did test it. And it does what it is supposed to. The argument essentially comes down to: does having your process working sets trimmed really help? I don't think so. Maybe it does with machines that have very low Memory usage, and though my memory is fuzzy I do recall RAMpage having a slight positive effect on my system when I ran XP with 96M of memory, though it could be argued that was partly because I thought it was going to have that effect so much. I also really don't see how, technically, it could be beneficial.
I found an interesting article of tangential relevance:
The working set of an application is trimmed when its top-level window is minimizedOne wonders if Windows Key-M, based on that, actually has the
exact same effect as many of the memory cleaner tools? (I don't think Win+D has the same effect)
