How can I keep a close eye on resource management?
Author
I was working at rewriting my game engine and one of the problems I came across was, even though I thought I had fixed it, my old code leaked memory. So I wrote new code. It took me a while to figure out how to not leak, and I tested it (by trying to modify the data of a supposedly deallocated object) and know I'm not leaking any more. But, how do I know how much memory my program uses and how efficiently it deallocates memory?
I tried monitoring my memory usage in Windows Task manager, but I found it inaccurate. Maybe my program DOES use 11,000K while resting with nothing but a diamond on screen, but it's slow to updated (even on the fastest update mode) and instead of giving me real-time what-my-program-is-using info, it gives what feel like approximations. Besides that, it takes five minutes for it to calculate how much memory my program is using before I can start testing.
Is there a good solution to getting realtime info on this?
You will need to overload new and delete so that you can intercept allocations and deallocations. You can pass the file and line number of the location of the new or delete to your overload and with that you can store a collection of allocations in a map of hash table and then at the end of your application you dump which ones have not been deallocated. Check out the code here, it should give you an indication of what is required.
Author
I thought of overloading new and delete to test IF it was working, but I KNOW it is because of the test I mentioned doing. I want statistical information about HOW it works. How much memory my program uses. Stuff like that.
Quote:Original post by Splinter of Chaos
I thought of overloading new and delete to test IF it was working, but I KNOW it is because of the test I mentioned doing. I want statistical information about HOW it works. How much memory my program uses. Stuff like that.
If you overload new and delete you can keep track of how much has been allocated (and how much of that has been freed) and hence figure out how much memory is currently allocated.
Take a look at this forum thread: clicky
I've found it quite handy for telling if there are any memory leaks. When exiting you'll get a memory report along with a dump of any unallocated memory areas. Example from my terribly leaking project.
0 bytes in 0 Free Blocks.
2057060 bytes in 187 Normal Blocks.
1016 bytes in 18 CRT Blocks.
0 bytes in 0 Ignore Blocks.
4828 bytes in 23 Client Blocks.
Largest number used: 8139718 bytes.
Total allocations: 16533279 bytes.
Dumping objects ->
c:\program files\microsoft visual studio 8\vc\include\crtdbg.h(1147) : {15625} normal block at 0x00B4A800, 32 bytes long.
Data: <Aseen::Update Dr> 41 73 65 65 6E 3A 3A 55 70 64 61 74 65 20 44 72
c:\program files\microsoft visual studio 8\vc\include\crtdbg.h(1150) : {15567} normal block at 0x024E0660, 30240 bytes long.
Data: < \? > 20 CC B7 BE 1C CC B7 BE 87 8E 5C 3F 20 CC B7 BE
...
...
Unfortunately it cannot say where the allocations occurred, however, by looking at the allocation sizes you can often guess where the leak occurs.
EDIT: Realized that you can in fact see where the allocations occurs, but since there is no complete callstack it doesn't help much.
I've found it quite handy for telling if there are any memory leaks. When exiting you'll get a memory report along with a dump of any unallocated memory areas. Example from my terribly leaking project.
0 bytes in 0 Free Blocks.
2057060 bytes in 187 Normal Blocks.
1016 bytes in 18 CRT Blocks.
0 bytes in 0 Ignore Blocks.
4828 bytes in 23 Client Blocks.
Largest number used: 8139718 bytes.
Total allocations: 16533279 bytes.
Dumping objects ->
c:\program files\microsoft visual studio 8\vc\include\crtdbg.h(1147) : {15625} normal block at 0x00B4A800, 32 bytes long.
Data: <Aseen::Update Dr> 41 73 65 65 6E 3A 3A 55 70 64 61 74 65 20 44 72
c:\program files\microsoft visual studio 8\vc\include\crtdbg.h(1150) : {15567} normal block at 0x024E0660, 30240 bytes long.
Data: < \? > 20 CC B7 BE 1C CC B7 BE 87 8E 5C 3F 20 CC B7 BE
...
...
Unfortunately it cannot say where the allocations occurred, however, by looking at the allocation sizes you can often guess where the leak occurs.
EDIT: Realized that you can in fact see where the allocations occurs, but since there is no complete callstack it doesn't help much.
Author
As I said, I already know that I'm not leaking, or at least in the worry-area, I want to know, real-time, what resources my program uses. The word I would like to emphasize is REAL-TIME. I tell my program jump; I don't want to know IF he did it, I want to know how high and connect that with the sight of seeing that on the left and looking right for the report.
And I don't care how much memory ONE OBJECT uses, I want to know how much ALL of them use together.
One last time, as I said in the first post, I don't want to know if my program is leaking memory.
Also, the code you linked to, Necator, didn't compiler because I don't have crtdbg.h. Looks like a Visual C++ thing.
And I don't care how much memory ONE OBJECT uses, I want to know how much ALL of them use together.
One last time, as I said in the first post, I don't want to know if my program is leaking memory.
Also, the code you linked to, Necator, didn't compiler because I don't have crtdbg.h. Looks like a Visual C++ thing.
It's actually quite simple to extend it to calculate a memory difference not only when exiting. And regarding the total usage, it prints that out quite nicely as well if you look at the lines:
...
Largest number used: 8139718 bytes.
Total allocations: 16533279 bytes.
...
However, it is true it's VC++ specific.
Unless you find something compiler/platform specific or find a memory manager package which can do it for you, your best bet is to overload the global new and delete operators as Dave and OrangyTang suggested. clicky.
...
Largest number used: 8139718 bytes.
Total allocations: 16533279 bytes.
...
However, it is true it's VC++ specific.
Unless you find something compiler/platform specific or find a memory manager package which can do it for you, your best bet is to overload the global new and delete operators as Dave and OrangyTang suggested. clicky.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
