An unsolicited testimonial

On November 25th, 1995, John Gotwals posted the following message in the C++ Compiler/Lang section of the Microsoft 32-bit Languages forum on CompuServe. (Message #295282, if you'd like to look it up. We also double-checked with John to see if it was OK to reproduce his message here. His response? "You have my permission to reproduce that message. And yes, MicroQuill has excellent products.")

Subj: More on VC 4.0's new
To: All
From: John K Gotwals, (CIS address)

NOTE: I do not own stock in MicroQuill, nor am I being paid to write what follows. Furthermore, although I have tried to follow correct procedures in making performance measurements, I can not guarantee that the data and my conclusions are valid. I present this information to the MSVC user community in the hope that several of you will check my results and report back your conclusions.

[This thread now contains 15+ messages, and no one has disputed John's conclusions. However, another SmartHeap user posted a similarly glowing testimonial. ed.]

I have an application using ObjectSpace's version of STL. In this application I create a linked list with a large number of elements (50,000 - 200,000). Each element contains a pointer to a record containing a random number of bytes, and the record length varies from 12 to 80 bytes. When the list is created, new is called once for each record creation as well as STL using new for its own memory management purposes.

With MSVC 2.2 the release performance was quite acceptable, although I had to "tune" the MSVC memory management by inserting the following two code statements at two strategic locations within my program:

    char *ptemp = new char[10000000];
    delete [] ptemp; 

I didn't like doing this because when my clients reviewed this code, they asked me why the "ficken" these two statements were in the code I had written. The only answer I had was to tell them that it helped improve the VC heap management performance tremendously.

When my UPS buddy delivered MSVC 4.0, I recompiled my program with the new version. Alas, the release performance had gone to hell! I am not writing about a few percentage points but a factor than can be as high as 10 or more! After some investigation I discovered that the problem appeared to be that new and delete were _much_ slower than in release 2.2. While the two tuning statements were no longer needed, the performance was completely unacceptable.

Following a suggestion made to me here on CServe, I contacted MicroQuill at 206.402.9400 and rush ordered a product called SmartHeap. I installed the SmartHeap professional memory management library and noticed a dramatic improvement in performance. In fact, the performance was even better than the 2.2 release, and I didn't have to insert the two screwball "tuning" statements mentioned above! Below are some quantitative data from my particular application as measured on a 66MHz DX2:

seconds   # of elements   System
  15          50,000      MSVC 4.0
   1.4        50,000      MSVC 4.0 with SmartHeap
  52         100,000      MSVC 4.0
   3.3       100,000      MSVC 2.2
   2.5       100,000      MSVC 4.0 with SmartHeap
   6.3       200,000      MSVC 2.2
   5.2       200,000      MSVC 4.0 with SmartHeap

Note that the figures for MSVC 4.0 do not scale linearly, and I didn't want to wait (overnight?) to get the value for 200,000 elements. To make a bad situation grave, the situation for delete appears to be very poor for MSVC 4.0 when compared with the others, but I didn't get quantitative data for delete.

-- John