previousupnext

5.5.4 Performance Under Contention

Contention performance is measured by increasing the thread-count parameter of the confidence test program. The tables show the duration in seconds of the churn phase; for the other phases LeapHeap was uniformly faster. The version of NT used for the uniprocessor tests has a performance bug affecting the heap building phase which would only make the full results confusing.

Microsoft heap versus LeapHeap on uniprocessor 1.3 GHz Pentium 4 machine with 128 MB RAM, running Microsoft Windows NT 4.0 SP4:

ThreadsNative HeapLeapHeap
1201199
2202198
4201194
8203189
16203186
32199178
64188162
128193163

Microsoft heap versus LeapHeap on quad 200 MHz Pentium Pro machine with 384 MB RAM, running Microsoft Windows 2000 Advanced Server:

ThreadsNative HeapLeapHeap
1588620
2321322
4179164
8188158
16191155
32193149
64187141
128197151
256195133

The results are somewhat counter-intuitive. Far from interfering with one another, concurrent threads did not slow down the native heap at all, and progressively increased the performance of LeapHeap. This behaviour may be tentatively ascribed to the large number of threads running in other processes, even on a vanilla NT installation. If there is only one 'HeapTest.exe' thread, whenever its timeslice expires the NT kernel will (let us assume) schedule several of these other threads, and even if they all yield the processor immediately a lot of time is lost in context switches. If there are many 'HeapTest.exe' threads, another such thread is as likely to be scheduled as some useless thread from an unrelated process, and more work gets done. With the native heap, this benefit is more or less masked by contention for the global lock, whereas inside the LeapHeap threads slip past one other frictionlessly. The improvement is dramatic, considering the modest proportion of total program time that the heap routines originally consumed.