VS2010 - C++ EXE size reduction, how?

[Florent Heyworth]

The merge pragmas can make for tricky output sometimes - strange about the optimize gsy pragma - could it be that some additional linker/compilation options were set that created a conflict. All's well that ends well

Cheers, Florent

[Frederick J. Harris]

That is 3 Kb less than PB...

That's something of a general truth there Patrice.  C++ programs will always be larger than PowerBASIC programs if the includes are <string> or <cstring> because the whole C++ Standard Library's String Class will be compiled into your code.  The C++ String Class is a rather complicated beast.  At its most basic level it is represented as a Standard Template Library ( STL ) instantiation of the basic_string template where a char or wchar_t is passed in. Then there are a lot of member functions associated with both the resulting string class, and the underlying STL basic_string container.  Its very fast but at times difficult to use. 

I mostly use CodeBlocks GNU to code, and my basic Hello World with the String Class is about 45K.  With just stdio.h and string.h its only about 6K.  So you can see the difference.  Whether to use it or not depends on how bad one needs it.  I would think in the heavy duty graphics programming you do  you wouldn't have more then incidental use for advanced capability string handling routines such as Replace, Parse, InStr, etc.  So you can save a lot by doing what you did.  The only other alternative is to do what I did and that's create my own string class.  It saves me about 20 - 25 K or so on the one in the Std Lib.

Of course, the beauty of PowerBASIC is that all that logic is built into the compiler, so it doesn't have to be written into one's executable.  With C++, all that logic ends up in the executable. 

 

[Edwin Knoppert]

>Of course, the beauty of PowerBASIC is that all that logic is built into the compiler, so it doesn't have to be written into one's executable.  With C++, all that logic ends up in the executable.

The current PB versions add functionallity in blocks and not per function.
A GetAttr() for example seems to add much more than only a simple wrapper to the Windows SDK.
Maybe the new upcoming version may reduce the size again, maybe the internals are also stuck in SLL kind of libraries (embedded or so) and maybe it now takes what is requested only.

Note that i little care if the app is 100KB or 10KB, as long it ain't megabytes of difference it's fine by me
At least i would be very pleased with the new behaviour.

[Edwin Knoppert]

Code Select Expand


PowerBASIC for Windows
PB/Win  Version 9.01
Copyright (c) 1996-2009 PowerBasic Inc.
Venice, Florida USA
All Rights Reserved

412 bytes compiled code, 1576 bytes RTLibrary,
0 bytes string literals, and 1872 bytes dgroup.
Executable stack size:  1048576 bytes.
Disk image: 5120 bytes   Memory image: 3448 bytes.


Code Select Expand


428 bytes compiled code, 3067 bytes RTLibrary,
8 bytes string literals, and 1880 bytes dgroup.
Executable stack size:  1048576 bytes.
Disk image: 7168 bytes   Memory image: 4955 bytes.


[Patrice Terrier]

>Maybe the new upcoming version may reduce the size again

It is my experience that each new PB version didn't reduce the size of my own code, but instead each new release make it larger.
No surprise there, because every new features that are encapsulating the core API, are indeed adding more bytes to the code.
A good example of this, is to use the built-in PowerBASIC I/O facilities, if you rather use the core CreateFile API, you will see a significative file size reduction.
And this is the same when you use FORMAT instead of STR$ just to convert number to string. Non-speaking of the overhead of DDT over SDK.

This is the reason why a strict SDK coder, like myself, is very interrested to check wich language is able to produce the smallest code, trying to use only the Windows built-in API.

So far i would say that for my HUDplus project, the C++ 25 Kb and the PB 9.05 28 Kb are very similar, and they are both working at the same speed.

...

[Edwin Knoppert]

>This is the reason why a strict SDK coder, like myself, is very interrested to check wich language is able to produce the smallest code, trying to use only the Windows built-in API.

What reason?

[Frederick J. Harris]

For the 3K of difference Patrice its probably not worth anywhere near the effort, but I expect removing Win32Api.inc and just declaring/defining only what's needed could easily save that difference.  Or maybe you already did that?

From what I read before you and Florent were doing Win64.  I'm taking from that that the Win64 compiles don't affect resulting program sizes too much.  I need to jump on this Win64 bandwagon I guess and get myself one.  I just keep putting it off. 

[Patrice Terrier]

Edwin--

What reason?

I avoid to use extra encapsulation when there is no need for me to use them, because i have been programming long ago before these encapsulations have been made available. Using the core API, allows me to produce smaller and faster code, and this is the way i like it.  


Frederick--

but I expect removing Win32Api.inc and just declaring/defining only what's needed could easily save that difference.  Or maybe you already did that?

Yes, i already did that

From what I read before you and Florent were doing Win64.  I'm taking from that that the Win64 compiles don't affect resulting program sizes too much.

From my own test, the EXE size difference is something around 1.35 larger.

...

[Patrice Terrier]

While the size of the C++ exe is only 25K, i must say that is also require the installation of the C++ runtime.
Aka: vcredist_x86.exe

This means that PB's code, is definitly much smaller, because it doesn't require any runtime! 

...

[Frederick J. Harris]

That issue with the redistributable really caught me by surprise Patrice!  I purchased VS 2008 ( VC9 ) summer before last.  I had been using VC6 from way back in Win 98 times.  With that old version it defaulted to the non - runtime version.  Microsoft changed the defaults somewhere along the way between vc6 and vc9, and it took a long time for me to catch it, much to my embarressment!  Right from the start I couldn't believe how small the executables were from VC 9!  I was amazed!  Just couldn't believe it!  It never occurred to me that my executables required the VC9 runtime!  I was comparing apples to oranges.

The way I finally discovered it, is somehow or other I tried to run one of my VC9 produced exes on one of my Win 2000 machines.  Since then I've been seeing what I expected; compiled with VC9, my executables are fairly large.  For this reason (and others), I tend to use the GNU Mingw compiler suite with CodeBlocks.  It produces somewhat smaller exes.  I don't have hard figures on it, but off the top of my head I'd estimate 5% to 15% smaller.  The only thing is, I've never been able to have much success with it doing low level COM work.  For that I have to resort to VC6 or VC9.  The problem involves DEF files as related to creating COM servers.

You know, I recall the discussion you started several months ago when you were wanting to know how to do explicit linking with PowerBASIC Dlls from C++.  That topic interests me, and I could see at some point taking it up.  It is a PIA to have to do the LoadLibrary() / GetProcAddress() thing and use pointers to call functions in PB Dlls.

[Patrice Terrier]

I have again the problem of the C++ run-time

The program can't start because MSVCP100.dll is missing from your computer. Try reinstalling the program to fix this problem

I couldn't remember the switch to use to get rid of the Micrsoft's Visual C++ Redistributable Package

Note: I am already using the Multithread /MT switch...

[Brice Manuel]

The runtimes are one of the major issues with VC++.    Not everybody has the runtimes installed for the newer versions of VC++.  It is not just EXEs.  DLLs will require those runtimes, too.  This was the main reason I dropped my DX9 2D engine that was written in VC++ 2008.  It worked fine, but so many people did not have the necessary VC++ runtimes, that it was more hassle than it was worth.  At some point, I should rewrite it in OpenGL.

[Patrice Terrier]

The problem is that i am using <vector> <string> and a few others as well, requiring the Standard C++ Library that's really a big problem when you come from PB where everything is part of the EXE including the runtime.

[Mike Stefanik]

They're convenient for sure, but if size is a real issue for you, there's nothing that says that you have to use those standard templates in your code. If you want to take the time, you can implement your own dynamic string and array handling. And if size is really, really an issue then you just go with straight ANSI C and no C++ classes/templates whatsoever and your own trimmed-down C runtime library (e.g.: Tiny C Runtime Library). It all depends on how much work you want to throw into it.

[Patrice Terrier]

Mike--

What stress me much, is that even my new WinLIFT64.dll and GDImage64.dll seems to need this extra MSVCP100.dll, i was not prepared to that