Performance Issues

We are confident that SmartHeap significantly out-performs most heap managers. We have benchtests that demonstrate this, and we offer the benchtest source for download so users can run the tests themselves. If you have your own benchtest program for evaluating heap managers, please read this. If you are not seeing any performance improvement in an app linked with SmartHeap, we would recommend generating a map file to verify that SmartHeap is indeed properly linked in. A properly linked EXE/DLL will have the symbol "SmartHeap_malloc" in its map file. For tips on how best to link your Win32 app to SmartHeap, please see our Knowledge Base article on linking.

That being said, performance improvements in a specific app are dependent on:

  1. How intensively the app exercises heap memory management. (If mem management isn't a performance bottleneck for your app, then one mem manager may appear to do as well as another.)
  2. The amount of memory available on the machine at runtime.
SmartHeap will improve performance most when the app is memory management intensive and the machine is tight on RAM relative to the app's footprint. We would recommend that performance tests be conducted on target end-user configurations rather than on fast 64M+ development machines.

Some other considerations:

  • Only the SmartHeap runtime libraries are optimized for performance. Do not use the debug libraries for your performance tests.
    Debug SmartHeap performs as well as most debug libraries and better than some, but it is designed to catch bugs, not to run fast.
  • SmartHeap's default configuration does not always give the best results.If you are simply linking SmartHeap to your application and not using the SmartHeap API, SmartHeap will use its default settings to manage the heap. These settings are chosen to optimize performance for a "typical" application. If your app isn't what we would call typical, you may need to tweak these settings to get optimum performance. In particular, apps that allocate a lot of large blocks (4 K and above) may benefit from increasing the page size to 64 K. SmartHeap sub-allocates blocks smaller than 1/4 of the page size from the pool and makes system calls for larger blocks (the 4 K figure above assumes a default page size of 16 K). Increasing the page size will result in fewer system calls. See the API Reference for MemDefaultPool and MemPoolSetPageSize in the Programmer's Guide for more info. There is additional information and tips on page size in Appendix C (see below) and at the back of the SmartHeap Getting Started guide.
    Note for SmartHeap 4/SmartHeap-SMP users: Usage for MemDefaultPool and MemPoolSetPageSize changed in SmartHeap 4/SmartHeap-SMP. Click here for details.
    Please refer to Appendix C of the SmartHeap Programmer's Guide for more information on evaluating and maximizing SmartHeap's performance, and contact MicroQuill tech support if you have any unanswered questions.
    Note for SmartHeap 4 and SmartHeap-SMP users:
    SmartHeap 4 and SmartHeap-SMP target multi-threaded apps. Single-threaded apps will not benefit from the unique optimizing code in these versions. In a single-threaded app, SmartHeap 4 will perform much like SmartHeap 3.x. This is still faster than the compiler heap managers. However, if your single-threaded app already links with SmartHeap 3.x then an upgrade to SmartHeap 4 may not dramatically improve performance.