In a message dated 07-2895, Jonathan De Boyne Pollard said to Peter Fitzsimmons:

JP|  IBM VisualAge C++ may seem a lot slower than Borland C++, but that's
  |  not because its optimiser is working its little brains out.  It's
  |  because the compiler is so damned *big* that it is thrashing your
  |  system to death.

Hee hee!  Thanks for the excuse to post the following time/size charts.
This is just in order to show  the end-product of a couple of OS/2
compilers "relative" to each other.

Scenario:  A rebuild-for-release of the ObjectPM class library.  For this
release, we created a "mega-make" file that compiled the
libraries and created DLL's for BC++ (using bcc2.exe), IBM CSet++ and
Metaware's latest C++.  It also recorded elapsed times.  Someone was
supposed to count "lines of code", as if that means anything.  I
don't have that figure handy. Whatever the case, the amount of code
involved is "substantial", but not unbelievable.  These compiles
took place on a 486DX66 with 24MB of RAM, ample disk space, running over
LAN Server overnight (minimal-to-no network interference, but some memory
use).

Resulting DLL sizes and time-to-compile is reported (Min:Sec).
Optimizations on, debugging off.  No precompiled headers (BC++ times would
have been substantially lower ... dunno about the others).

                       ObjectPM Mega-Make Results

              Base Set DLL's                Windowing DLL's
              --------------                ---------------
               Size / Time                    Size / Time

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


We also came up with this list of RTL requirements:

    BC++      210K
    CSet++    291K
    HC++      311K

Watcom absent?  You bet ... still too many problems to add support for
Watcom.  And, they've ignored all of my inquiries regarding same.  Maybe
they can find BlueSky for OS/2, I dunno.

This makes no arguments for "efficiency" or "execution
speed", but I'd have great trouble believing that you're gonna see a
great deal of difference between two apps painting the same notebook page. 
I've been asked to come up with a performance benchmark for these ...
anyone have any ideas?  If I do test something like notebook performance,
I'd just be measuring a great deal of PM code in addition to the
"test" code.  I could do a bunch of sorted-list insert, or fill
one of our "cellbox" with 10,000 items ... is there anything out
there to use as a model or give me some ideas?

I'm still a big fan of the Borland Compiler, even after years of thinking
it was just a toy.  It's doing the job for me personally, and for the
consulting work our company does.  We have Cset++.  We have HC++.  And we
have BC++.  We use mostly BC++, with some Metware thrown in because of
their great SOM helpers.  The consensus is that, around here at least,
CSet++ is too slow and offers no real advantage over the
"others".  Particularly if you don't need their even-hungrier
ICLUI/OCL stuff.

Nick

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

--- InterPCB 1.50