In a message dated 08-0295, Peter Fitzsimmons said to Nick Knight:

 NK> BC++          123,488 /  3:46               380,431 / 13:18
 NK> CSet++        196,520 /  8:28               703,571 / 23:54
 NK> Metware C++   128,166 / 15:08               358,237 / 54:02


PF|Can you please post the link options you used?  For best results with IBM
  |Cset,  you should never call link386 directly -- always go through ICC
  |(and make sure you don't use "/tl-").

That's pretty pertinent ... I guess I should have included these.  Let me
decipher this make file a second; it's ugly and I try not to even look
inside :).  I'm piecing this together from about a million separate
$(definitions)  ...  again, these are the non-debugging "release"
settings:

Borland
-------
bcc2 /c /V /sm /X /xd- /O2 /d /DNDEBUG
tlink /Tod /c

IBM CSet
--------
icc.exe /Q+ /C+ /Gd+ /Ge+ /Gm+ /Wpro /D_MT
    (some modules add /Tdp, /Ss+ or /Si+ ) link386.exe /NOD /M /NOI /NOLOGO /ALIGN:16

Metware
-------
hc.exe -c -Hthread -O
link386.exe /NOD /M /NOI /NOLOGO /ALIGN:16

There were settings for Watcom in the make, also, but AFAIK, all attempt to
supporting it have been abandoned.

PF|In particular,  you should make sure that all three linkers use the same
  |options for:

PF|        Alignment (/A:4)
  |        Exepack   (/ex)
  |        Base      (/base:0x10000)

Alignment may be a big factor in resulting DLL's.  I'll point this out to
Chas (keeper of the MegaMake) on Monday, and relay the settings above.  I'm
sure Borfland uses 4 byte alignment by default.  Perhaps the 16-byte
alignment is an old perfromance trick or something, but you're right, the
links are not equally specified.  If we can shrink the size of the CSet
DLL's, everone will be happy.  Thanks.

The alignment setting isn't responsible for the slowness of compiles, tho.
For large projects this is a significant "cost" difference.  I'll
also add that we finally fired up our VisualAge C++.  The comment I heard
was "man, this thing is a horrible pig in 16 MB".  I have no
other envorinment data to report, just that I'm certain that the programmer
(er, actually, "the boss" :) had taken the speed of the previous
CSet offering into consideration before making that comment.  In other
words, I believe it to be slower yet. Whether there are other benefits to
be gained from it, only time will tell. The IBM folks sure put on a slick
presentation, tho.

The other fellow that responded has inspired me to write a non-PM intensive
test app.  Perhaps I'll build a massive sorted collection and time some
repetitive operations.  I'll think of a few other things, and even throw in
a PM window/control that uses our library code heavily.

If you have any other suggestions that might help obtain optimum
performance from CSet++ (with the above "current" settings in
mind), please let me know.

Nick

.. If at first you don't succeed, work for Microsoft. -- MR/2 2.26 #0

--- InterPCB 1.50