Why the size of the VC++ produced binary is so huge?

[Greg Stoch]

Hi,

I'm newcomer to Microsoft product (VS.net 7.0, C++) and need to understand,
why the binary code obtained using VC++ compiler is so huge as compared to
the code by Borland C++ 5.02 (the same source).

The source code is standard C++, without any extensions, just standard
libraries are statically linked in (/ML for VC++, Single Threaded). The
respective sizes are:
52kb for BC.5.02 and 120kb (!) for VC++ 120kb. Release versions, of course.

Could you make a suggestion how to understand this result? Is it just poor
MS compiler or there are deeper reasons? (I have heard that some programmers
try to hook up other compilers (like gcc) to VS environment). Or, perhaps, it
is my mistake? - what is wrong then? Could you help me with your general
opinion?

Thank you,
Greg

[Carl Daniel [VC++ MVP]]

"Greg Stoch" <Gr*******@disc ussions.microso ft.com> wrote in message
news:E7******** *************** ***********@mic rosoft.com...

Hi,

I'm newcomer to Microsoft product (VS.net 7.0, C++) and need to
understand,
why the binary code obtained using VC++ compiler is so huge as compared to
the code by Borland C++ 5.02 (the same source).

The source code is standard C++, without any extensions, just standard
libraries are statically linked in (/ML for VC++, Single Threaded). The
respective sizes are:
52kb for BC.5.02 and 120kb (!) for VC++ 120kb. Release versions, of
course.

Could you make a suggestion how to understand this result? Is it just poor
MS compiler or there are deeper reasons? (I have heard that some
programmers
try to hook up other compilers (like gcc) to VS environment). Or, perhaps,
it
is my mistake? - what is wrong then? Could you help me with your general
opinion?

For most cases, my opinion would be: who cares? 52Kb and 120Kb are both 0
size by today's standards. That difference in size will likely remain as an
offset as your program gets larger, not a ratio (i.e. on a 16Mb EXE image,
the VC image might still be 70K bigger, but it won't be 18Mb bigger. It
might even be smaller).

If you really want to see the difference, generate detailed linker maps with
both compilers and identify the corresponding parts. Most likely, the
difference is in the size of the staticly linked standard library, and that
size difference probably mostly equates to differences in standards
conformance.

If you're interested in producing a tiny executable so that people with
glacially slow internet connections can download it, you might want to do a
bit of searching on the 'net for "C Run Tiny", which is a minimal CRT for
VC++.

-cd

[Tomas Restrepo \(MVP\)]

Greg,

Could you make a suggestion how to understand this result? Is it just poor MS compiler or there are deeper reasons? (I have heard that some
programmers
try to hook up other compilers (like gcc) to VS environment). Or, perhaps, it
is my mistake? - what is wrong then? Could you help me with your general
opinion?
For most cases, my opinion would be: who cares? 52Kb and 120Kb are both

0 size by today's standards. That difference in size will likely remain as an offset as your program gets larger, not a ratio (i.e. on a 16Mb EXE image,
the VC image might still be 70K bigger, but it won't be 18Mb bigger. It
might even be smaller).

Besides Carl's comments, it might be also possible that section alignment
within the binary image might be an issue. playing with the various linker
switches like /OPT (particularly the old /OPT:Win98) and changing section
alignment (/align) might be valid options if you want to get as small as
possible...
--
Tomas Restrepo
to****@mvps.org

[Ioannis Vranos]

Greg Stoch wrote:

I'm newcomer to Microsoft product (VS.net 7.0, C++) and need to understand,
why the binary code obtained using VC++ compiler is so huge as compared to
the code by Borland C++ 5.02 (the same source).

The source code is standard C++, without any extensions, just standard
libraries are statically linked in (/ML for VC++, Single Threaded). The
respective sizes are:
52kb for BC.5.02 and 120kb (!) for VC++ 120kb. Release versions, of course.

Could you make a suggestion how to understand this result? Is it just poor
MS compiler or there are deeper reasons? (I have heard that some programmers
try to hook up other compilers (like gcc) to VS environment). Or, perhaps, it
is my mistake? - what is wrong then? Could you help me with your general
opinion?

Are you using any VC++ optimisation switches? Perhaps you have VC++
standard which provides no optimisation switches?

--
Ioannis Vranos

[Hendrik Schober]

Greg Stoch <Gr*******@disc ussions.microso ft.com> wrote:

[...]
52kb for BC.5.02 and 120kb (!) for VC++ 120kb. Release versions, of course.
BC 5.02 is a very ancient compiler (it's
almost a decade old) and probably comes
with a rather ancient rtl, too. That by
itself might explain the difference.
[...]
Greg

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett

[Greg Stoch]

> Are you using any VC++ optimisation switches? Perhaps you have VC++

standard which provides no optimisation switches?

Of course. Good point, I've forgotten to mention that optimizing "for size"
switch increases (!) the size of the output binary by 2kb. :):):):):) . Any
ideas?

Cheers, Greg

"Ioannis Vranos" wrote:
Greg Stoch wrote:

I'm newcomer to Microsoft product (VS.net 7.0, C++) and need to understand,
why the binary code obtained using VC++ compiler is so huge as compared to
the code by Borland C++ 5.02 (the same source).

The source code is standard C++, without any extensions, just standard
libraries are statically linked in (/ML for VC++, Single Threaded). The
respective sizes are:
52kb for BC.5.02 and 120kb (!) for VC++ 120kb. Release versions, of course.

Could you make a suggestion how to understand this result? Is it just poor
MS compiler or there are deeper reasons? (I have heard that some programmers
try to hook up other compilers (like gcc) to VS environment). Or, perhaps, it
is my mistake? - what is wrong then? Could you help me with your general
opinion?

Are you using any VC++ optimisation switches? Perhaps you have VC++
standard which provides no optimisation switches?

--
Ioannis Vranos

[Greg Stoch]

> BC 5.02 is a very ancient compiler (it's

almost a decade old) and probably comes
with a rather ancient rtl, too. That by

Sure. But this is rather about standards. When I compile C++ (standard) i
don't see the reason for inreasing the code (the same as for pure C).
Especially for static linking. I agree to "some" extent: also standards
became "larger"; twice seems "too much" though. I would rather expect the
nowadays compilers to produce even smaller code (for standard C++), they are
mature now.

Greg

"Hendrik Schober" wrote:
Greg Stoch <Gr*******@disc ussions.microso ft.com> wrote:

[...]
52kb for BC.5.02 and 120kb (!) for VC++ 120kb. Release versions, of course.

BC 5.02 is a very ancient compiler (it's
almost a decade old) and probably comes
with a rather ancient rtl, too. That by
itself might explain the difference.

[...]
Greg

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett

[Greg Stoch]

"Carl Daniel [VC++ MVP]" wrote:

For most cases, my opinion would be: who cares? ....
50kb vs. 120kb was the example. Essential is the nature of this "code
increase" (valid for any size) and you actually answered this below, thank
you. If this is the offset only - then allright. If it scales with the
project size - then it is likely something very sad about the compiler.
That difference in size will likely remain as an offset....not ratio...
Exactly. I just hope that it doesn't scale with the size.
If you're interested in producing a tiny executable so that people with

glacially ... searching on the 'net for "C Run Tiny", ...

Thanks, that's thel hint, I'll do it.

Greg

[Ioannis Vranos]

Greg Stoch wrote:

Of course. Good point, I've forgotten to mention that optimizing "for size"
switch increases (!) the size of the output binary by 2kb. :):):):):) . Any
ideas?

Cheers, Greg

Perhaps may you post the code to experiment ourselves? :-)

--
Ioannis Vranos