Benfits/drawbacks of disabling the memory manager
by Richard McKinney · in Torque Game Engine · 03/08/2007 (11:44 am) · 7 replies
I see a lot of posts about disabling the memory manager to get stl working (although the common solution looks more like redirection and still using it), but I haven't seen anything about the merits of using or not using the memory manager once hitting the production stage.
I disabled the memory manager yesterday and noticed that in doing so shaved 26 megs of ram off our game at runtime (eg: from 98 to 73 in our low detail path, 117 to 91 in high detail). I ran some tests and see no degredation in performance (it's actually running 2-3 fps faster). Accurate tests over time have not been performed to see what happens once the heap starts to get fragmented, so I'm wondering if anyone else is doing this and maybe has some more metrics. Tests were done using the private bytes performance counter and not just looking in task manager.
I played around with the MinPageSize in platformMemory.cc just to make sure I wasn't hitting a page boundary edge case, but the numbers were the same, and I shouldn't have seen more than an 8 meg difference anyway (plus the minimal overhead for each page and header).
There are two main reasons for the custom memory manager in my understanding: to improve performance by avoiding heap fragmentation for faster allocs and less page faults, and reducing the number of required allocs and frees, and to provide debugging benefit from having the guards and leak detection. Assuming we're heading towards production and won't gain benefit from the latter two any more (debug guards were disabled in my control build with the TMM) we're only concerned with performance now. The performance I'm seeing with it disabled is slightly better in short tests, and the benefit of 25 megs for free means being playable on 128 meg systems versus playing horribly on them (unless I can somehow find another way to shave off such a huge chunk).
The only mention I've seen of disabling the TMM for a production build is from Tom Spilman here saying he did it to "to vastly reduce plugin memory usage on large maps" in the Torque Pipeline for Cartography Shop.
I haven't delved in deep enough yet to know exactly what's causing all the overhead in the first place, and first wanted to query if any other comparison work has been done in this area given more modern or varying OS/CRT performance and whether I'm heading down a wasteful path or not (eg: profiled worse performance over time).
I disabled the memory manager yesterday and noticed that in doing so shaved 26 megs of ram off our game at runtime (eg: from 98 to 73 in our low detail path, 117 to 91 in high detail). I ran some tests and see no degredation in performance (it's actually running 2-3 fps faster). Accurate tests over time have not been performed to see what happens once the heap starts to get fragmented, so I'm wondering if anyone else is doing this and maybe has some more metrics. Tests were done using the private bytes performance counter and not just looking in task manager.
I played around with the MinPageSize in platformMemory.cc just to make sure I wasn't hitting a page boundary edge case, but the numbers were the same, and I shouldn't have seen more than an 8 meg difference anyway (plus the minimal overhead for each page and header).
There are two main reasons for the custom memory manager in my understanding: to improve performance by avoiding heap fragmentation for faster allocs and less page faults, and reducing the number of required allocs and frees, and to provide debugging benefit from having the guards and leak detection. Assuming we're heading towards production and won't gain benefit from the latter two any more (debug guards were disabled in my control build with the TMM) we're only concerned with performance now. The performance I'm seeing with it disabled is slightly better in short tests, and the benefit of 25 megs for free means being playable on 128 meg systems versus playing horribly on them (unless I can somehow find another way to shave off such a huge chunk).
The only mention I've seen of disabling the TMM for a production build is from Tom Spilman here saying he did it to "to vastly reduce plugin memory usage on large maps" in the Torque Pipeline for Cartography Shop.
I haven't delved in deep enough yet to know exactly what's causing all the overhead in the first place, and first wanted to query if any other comparison work has been done in this area given more modern or varying OS/CRT performance and whether I'm heading down a wasteful path or not (eg: profiled worse performance over time).
About the author
#2
Other than that, I think you have covered the pros/cons pretty thoroughly.
03/08/2007 (12:07 pm)
One other consideration is that with the memory manager, "freeing" memory means that it doesn't necessarily lose the data that was in that memory location until it is reused and it can still be addressed by other parts of the code without crashing (naughty). Disabling the memory manager will expose these bugs really quickly since Windows is a lot more agressive about clearing the data out on a free and possibly handing the memory off to something else. These bugs can be hard to track down since the free's and the access's can happen pretty far apart. So you will want to test very thoroughly and very carefully because things that used to work fine may now blow up.Other than that, I think you have covered the pros/cons pretty thoroughly.
#3
03/08/2007 (12:24 pm)
Quote:Disabling the memory manager will expose these bugs really quickly.. seems like a good thing ?
#4
Thanks for the help so far Tim and Matt.
03/08/2007 (12:44 pm)
@Orion: Absolutely. We had one access violation pop up on the first run which immediately pointed out a bug in an area that is very difficult to test all cases for, which otherwise would have likely slipped through. I want all the crashes I can get!Thanks for the help so far Tim and Matt.
#5
-Prairie Games
03/08/2007 (1:08 pm)
The OSX build actually requires the memory manager to be disabled. We ran into this when doing our universal binary.-Prairie Games
#6
03/08/2007 (2:19 pm)
We have had it disabled in release builds as well. I honestly can not tell much difference, but I have not profiled it. 
#7
It is a pain that STL doesn't work with it, but, at least for me, for all the frustrations I've had with it, and modifications I've done to it, I still find that it is a valuable tool.
03/08/2007 (3:13 pm)
The memory manager is going to save you time if you are making a large number of dynamic allocations, which you should not be doing anyway (use FrameTemp!). The primary advantage to using it is tracking down memory leaks. Since there are other tools which help do this, as well, there is no reason you should think you are "forced" to use the memory manager. It is a pain that STL doesn't work with it, but, at least for me, for all the frustrations I've had with it, and modifications I've done to it, I still find that it is a valuable tool.
Tim McClarren
Default Studio Name
We turned it off in our production builds some time ago.
There was probably a time when the built-in manager was a win, performance-wise, but I'm not sure that's still the case.
We also don't have it turned on for our test builds. We have used other tools for finding memory leaks and corruption.
And, the benefits of being able to use STL, in my estimation, for outweigh the benefits we might have gotten from the Torque memory manager.