Every so often I see "Speed Up Your PC" programs that offer a RAM cleaning feature.
They claim to defrag and free up unused memory like a garbage collector or something... not sure.
Here are some examples:
http://www.softpedia.com/get/Tweak/Memory-Tweak/Clean-Ram.shtml
http://download.cnet.com/Instant-Memory-Cleaner/3000-2086_4-10571833.html
http://www.uniblue.com/software/speedupmypc/
I'm interested in learning about the Win32 C API's that they are using, if anyone has knowledge.
I've heard about the ProcessIdleTasks() in advapi32.dll trick, but doesn't look too legit looking at the documentation on that function.
If you really insist on doing this, you could enumerate processes, open a handle to each, and call SetProcessWorkingSetSize(process_handle, -1, -1); for each (but you really don't want to do this).
I don't know how those particular programs work, but in the past I saw the source to a similar program.
It basically allocated a ton of RAM in one shot and then released it.
System RAM was "freed" because other programs had to swap to the disk.
Related
my program is running and creating variables, I need to know what's the total of Bytes these variables take.
I don't want to know how much is the physical memory space that the system gives my program to be executed, I know I can open the processes manager and find out.
I neither want to write into my code some sizeof and agregations so I can know the total size of the variable pool (let say the code is too complex to be modify like that).
Finally I'm using Microsoft VC++ 2010 Express, I just want to know if there is a workspace which monitor that kind of information.
Thanks in advance.
Check this out: Memory Performance Information . There are few metrics of a running process you might be interested in, you will primarily want private bytes, and this data is available both programmatically or through tools like Performance Monitor. You can also enumerate heaps of the process with GetProcessHeaps (and even HeapWalk if you need details) and check heap allocation sizes directly.
Valgrind Massif profiler is a great tool (see here ) but only for Unix/Linux I think. In your case, on Windows I think Insure++ or softwareverify are good choices (they are commercial tools).
A free alternative is Google's tcmalloc which provides a heap profiler here
I thought I would ask the experts - see if you can help me :o)
My son has written C++ code for Collision Detection using Brute Force and Octree algorithms.
He has used Debug etc - and to collect stats on mem usage he has used windows & task manager - which have given him all the end results he has needed so far. The results are not yet as they were expect to be (that Octree would use more memory overall).
His tutor has suggested he checks memory once each is "initialised" and then plot at points through the test.
He was pointed in the direction of Valgrind .... but it looked uite complicated and becaus ehe has autism, he is worried that it might affect his programmes :o)
Anyone suggest a simple way to grab the information on Memory if not also Frame Rate and CPU usage???
Any help gratefully received, as I know nothing so can't help him at all, except for typing this on here - as it's "social" environment he can't deal with it.
Thanks
Rosalyn
For the memory leaks:
If you're on Windows, Visual C++ by Microsoft (the Express version is free) has a nice tool for debugging and is easy to setup with instructions can be found here; otherwise if you're on Linux, Valgrind is one of the standards. I have used the Visual C++ tool often and it's a nice verification that you have no memory leaks. Also, you can use it to enabled your programs to break on allocation numbers that you get from the memory leak log so it quickly points you to when and where the memory is getting assigned that leaks. Again, it's easy to implement (just a few header files and then a single function call where you want to dump the leaks at).
I have found the best way to implement the VC++ tool is to make the call to dump the memory leaks to the output window right before main returns a value. That way, you can catch the leaks of absolutely everything in your program. This works very well and I have used it for some advanced software.
For the framerate and CPU usage:
I usually use my own tools for benchmarking since they're not difficult to code once you learn the functions to call; this would usually require OS API calls, but I think Boost has that available and is cross-platform. There might be other tools out there that can track the process in the OS to get benchmarking data as well, but I'm not certain if they would be free or not.
It looks like you're running under a windows system. This isn't a programming solution, and you may have already tried it (so feel free to ignore), but if not, you should take a look at performance monitor (it's one of the tools that ships with windows). It'll let you track all sorts of useful stats about individual proceses and the system as a whole (cpu/commit size etc). It plots the results for you as a graph as the program is running and you can save the results off for future viewing.
On Windows 7, you get to it from here:
Control Panel\All Control Panel Items\Performance Information and Tools\Advanced Tools
Then Open Performance Monitor.
For older versions of windows, it used to be one of the administrative tools options.
There are tools such as TSearch, Cheat Engine, etc. These are hacking programs for viewing and modifying parts of memory of another program.
If I am to create a C++ program that can see and modify other program's memory, how can I do that? What are some of the things I should be looking for?
This is not a feature of C++, it's under the control of the OS itself.
For example, Windows provides the ReadProcessMemory() API call so that you can get your grubby little hands on the memory of another process. And of course, the equivalent for writing as well so you can cause even more damage :-)
All this depends on having the correct privileges as well.
I'm not sure how Linux provides this but earlier UNIXes had "memory mapping" files like /dev/mem so you could get at the memory. There may be a per-process variant in the procfs file system which can give you access to the virtual memory of a specific process. That'd be the first place I'd start looking although others here will undoubtedly know more about that than I.
One way to do that is to write your own debugger.
That won't be easy, though. Good luck.
I am looking for a way to cure at least the symptoms of a leaky DLL i have to use. While the library (OpenCascade) claims to provides a memory manager, i have as of yet being unable to make it release any memory it allocated.
I would at least wish to put the calls to this module in a 'sandbox', in order to keep my application from not losing memory while the OCC-Module isn't even running any more.
My question is: While I realise that it would be an UGLY HACK (TM) to do so, is it possible to preallocate a stretch of memory to be used specifically by the libraries, or to build some kind of sandbox around it so i can track what areas of memory they used in order to release them myself when i am finished?
Or would that be to ugly a hack and I should try to resolve the issues otherwise?
The only reliable way is to separate use of the library into a dedicated process. You will start that process, pass data and parameters to it, run the library code, retrieve results. Once you decide the memory consumption is no longer tolerable you restart the process.
Using a library that isn't broken would probably be much easier, but if a replacement ins't available you could try intercepting the allocation calls. If the library isn't too badly 'optimized' (specifically function inlining) you could disassemble it and locate the malloc and free functions; on loading, you could replace every 4 (or 8 on p64 system) byte sequence that encodes that address with one that points to your own memory allocator. This is almost guaranteed to be a buggy, unreadable timesink, though, so don't do this if you can find a working replacement.
Edit:
Saw #sharptooth's answer, which has a much better chance of working. I'd still advise trying to find a replacement though.
You should ask Roman Lygin's opinion - he used to work at occ. He has at least one post that mentions memory management http://opencascade.blogspot.com/2009/06/developing-parallel-applications-with_23.html.
If you ask nicely, he might even write a post that explains mmgt's internals.
I've noticed that the native C++ application I'm working on has quite a large memory footprint (20MB) even before it enters any of my code.
(I'm referring to the "private bytes" measure in Windows, which as I understand it is the most useful metric).
I've placed a break point on the first line of the "main()" function and sure enough, the footprint is at 20MB when it reaches that.
The size of the EXE is only a couple of meg so that doesn't account for it.
I also deliberately removed all of the DLLs just to prove they weren't the cause. As expected it gets a "Dll not found" message, but the footprint is still 20MB!
So then I wondered that maybe it was the statically initialised objects which were the cause.
So, I added breakpoints to both "new" and "malloc". At the first hit to those (for the first static initialiser), the memory is already 20MB.
Anyone got any ideas about how I can diagnose what's eating up this memory?
Because it seems to be memory outside of the usual new/malloc paradigm, I'm struggling to understand how to debug.
Cheers,
John
It might be that you're pulling a lot of libraries with your app. Most of them get initialized before execution is handed over to your main(). Check for any non-standard libraries you're linking against.
EDIT: A very straightforward solution would be to create a new project and just link the libraries you're using one by one, checking memory usage each time. Even though it's an ugly approach, you should find the culprit this way.
There's probably a more elegant solution out there, so you might want to spare some time googling for (free) memory profiling solutions.
You might compile your app without debug information and see if this changes something, debugging ability eats quiet some memory.
On my system, a simple MFC app and an empty Delphi app both take about the same number of private bytes - around 400K. So if your app is grabbing 20Mb, it is definitely sometyhing that your application is doing, and not some OS bloat. You need to post more details of what your app does, what libraries it uses etc.