previousupnext

10 LeapHeap for Developers

LeapHeap is an end-user's tool, designed to work with existing NT applications. However application developers can target their application at LeapHeap and thereby reduce project complexity.

Targetting an application at LeapHeap does not mean that the application will not work with the native heap; it is a declaration that the application is developed without resorting to memory management workarounds and meets its performance specification when run in harness with LeapHeap.

When developing for LeapHeap, the only restriction is to avoid the HeapDestroy function. If heaps are destroyed, LeapHeap must be run with heap identifier tagging, which increases memory demand. Other than that, the difference in technique stems from a lack of constraints; natural programming methods become attractive. The memory overhead of LeapHeap is low, so large numbers of small allocations can be made (even so, it is worth remembering alignment losses). LeapHeap is a lock-free memory manager, so the number of threads active in the application need not be limited unless there is contention outside the heap. Consequently, thread pooling, I/O completion ports and similar artificial design overheads may be avoided.

There is no need to install LeapHeap on development machines early in the life cycle. The NT native heap has debugging facilities which may prove useful. LeapHeap can be introduced for stress testing and tuning of the application.

The following extract from the Microsoft Exchange Server section of the MSDN documentation illustrates the kind of decision that doesn't have to be made when developing for LeapHeap:

How an application uses its chosen memory allocators is just as important as choosing them in the first place. An application that spends a significant portion of its time in the heap allocator is not well-designed. It should be using custom allocators to create objects with less overhead.

Multithreaded server applications can use the following features of HeapAlloc to improve their performance:

Of course incorporating LeapHeap makes an IT installation that little bit more complicated, which has to be weighed against the benefits. There are ways of making the existing heap work better, like this suggestion also from the Exchange section of the MSDN:

Another option to consider is a package of memory allocation functions written for your application, which can implement multiple heaps serialized outside the HeapAlloc and HeapFree functions. Such a package can eliminate almost all heap contention by tracking which heap is busy and always trying to steer allocations to non-busy heaps. This is useful for per-thread heaps. When the heap is created, the parallelism can be specified, which controls the number of heaps.

As ever, it's a tradeoff.