The True Power of NEDMalloc

I have dabbled with using NedMalloc in X-Plane...it is faster than the built-in allocator. But sometimes you have to find the right problem to see scalability issues.

I've been hacking at an architecture change (probably going into X-Plane 940) that allows X-Plane to build 3-d forests on an arbitrary number of processors.

(Currently X-Plane 930 can only do this on one processor, albeit not the processor you use to draw the world and fly the plane.)

Going to KBTV with the highest tree settings on an 8 core Mac Pro we get these numbers for "preload" times (that is, the time to pre-generate all nearby forests, which is basically a memory-intensive operation (since the trees are so simple):

• 9.30: 1 core, 20 seconds.
• 9.40, OS allocator: 8 cores, 40 seconds.
• 9.40, NedMalloc: 8 cores, 2 seconds.

I am not making that up. The 8x or better speed-up isn't surprising, but what is incredible is the difference between the system allocator and NedMalloc with only 8 threads!

Heap Debugging (Memory/Resource Leak) with WinDbg

I recently had to do some heap debugging to solve an issue at work and it was a bit of a pain in the butt because there are several steps that I needed to take to set everything up. Here's what I had to do...

1. First, you need the Debugging Tools for Windows installed.
2. Open a command prompt and navigate to the debugging tools folder (usually C:\Program Files\Debugging Tools for Windows (x86).
3. Type "gflags.exe /i yourApplication.exe +ust" (without the quotes). This command creates a user mode stack trace database that will be used later.
4. Launch the application in WinDbg.
5. Recreate the error and then break into the debugger.
6. Run the command "!heap -s". This will display a summary of all of the current heaps. Find the one that seems to be bloated.
7. Run the command "!heap -stat -h " on the block that appears to be bloated. This will display statistics on the heap's allocations by allocation block size. My problem was that one resource type was being leaked so there was one block size that was used far more frequently than the others. Find that block size.
8. Run the command "!heap -flt s ". This will filter the heap to only show heaps of that particular size.
9. Now choose one of the UserPtr's in the list and run the command "!heap -p -a " on it. This will display information on that particular block. It should also include a stack trace from when that memory was allocated.
10. Remember to remove the global flags by doing "gflags.exe /i -ust" when you're done.