VS2010 - C++ EXE size reduction, how?

[Patrice Terrier]

I have translated a few of my WinLIFT/GDImage projects from PowerBASIC to VS2010 C++.

The resulting C++ EXE is more than 3.2 the size of the same PB EXE.
I have been playing with the C++ project optimisation settings, however i couldn't get something that could be significant to reduce the size.

Note : I am using the X86 platform with no MFC, and only native Win32 SDK calls.

Suggestion?

...

[Chris Boss]

Patrice,

Have you done any benchmarking comparing the speed of execution between VS2010 C++ and PowerBasic (9.0 or later) ?

I posted a simple example on CodeProject ( http://www.codeproject.com/Lounge.aspx?msg=3728478#xx3728478xx )(the Lounge forum discussions) and I got replies from one person who used C# and it appeared significantly faster than PowerBasic.
I could not tell whether C# was doing some "tricks" to appear faster (ie. shortcuts). PowerBasic does not use any of the old "tricks" to appear fast simply for benchmarking.

I would be interested to see how well PowerBasic does with actual code execution speed.

[Patrice Terrier]

You can make a comparison with the GDImage sprite Carousel demo project, that is available in C#, PowerBASIC, and WinDev (XP, VISTA/SEVEN).
And you can compare C++ and PB with the HUDplus project (VISTA/SEVEN aero).

All these projects can be downloaded from this forum.

I have the feeling than the C# carousel is faster than PB, but this is very subjective, and anyway the core GDImage graphic engine is the same, and it is written in... PB.

...

[Charles Pegge]

Patrice,

I would hazard a guess that the extra size is due to C++ string libraries. If this is the case then I think Frederick may have the answer - emulating Basic-style string functions.

With regard to speed, I would expect PB string management to be slower (flexibility tradeoff) than C++ but very little difference in Integers, Floats, and Function calls. There is not much scope for optimisation with these once you hit machine code bedrock.

Charles

[Theo Gottwald]

Why should it be needed to make so much circumstances.

You take both systems as they ship. Write your code and compare size and speed.
In real life people choose the system they like most.

From how it looks, from SYNTAX.

From my standpoint the PB program is just more readable because its BASIC.
I can find and fix error much faster. I can use the comfortable string engine.
And i know its rock-stable. I can count on it when i need it!
My customers won't have surprising bugs in their software!
No need to sent updates all 4 weeks (unless with new features!)

If you look at the adverisement for VS there is no word about speed or size.
They talk about bussiness, Teamwork, Usability etc.
Thats what counts in the mass market.

Would you choose another compiler because it has a "nose more speed" in a loop-benchmark?

If it has roughly the same size (ok PB is  even smaller!), and it roughly the same speed (its a bit faster this time!), then this is Ok.

In both systems you can go the one or other more complicated way to make smaller or faster things.
Thats available anywhere it depends on the programmer.

What counts is YOUR final choice.

Do you believe that other fathers have also beautiful daughters?
Do you want the slim one or the fat one  ? (Its your choice)

Is it ok, if she goes dancing sometimes and you have to cook?
Or you want one you can trust in any case?
It's your choice.

I decided for PowerBasic.

[Patrice Terrier]

Please,

I didn't start this thread to compare the merits of each compiler.

I am asking for suggestions on how to further reduce the size of a VS EXE, as i am still a C++ novice, and i want to learn from those who are using themselves VISUAL STUDIO 2010 Professional.

...

[Florent Heyworth]

Please,

I didn't start this thread to compare the merits of each compiler.

I am asking for suggestions on how to further reduce the size of a VS EXE, as i am still a C++ novice, and i want to learn from those who are using themselves VISUAL STUDIO 2010 Professional.

...

Hi Patrice

offhand there's not much I can tell you since you haven't provided enough information about the optimizations you are using. Some useful pointers to reducing size:
- don't use the heap manager (malloc, new, free and so on) but call Win32 memory functions (you mention you only use win32 calls so you should be good)
- don't use cout, printf, etc but again use Win32 equivalent (you mention you only use win32 calls so you should be good)
- don't use exception handling (well you should but we're talking about reducing size - turn off exception handling

Make sure you're building a Release as opposed to a Debug build (I'm sure you known this - just mentioning for the sake of completeness).
Some useful switches:

/Og (general optimize) /Os (optimize size) /Oy (don't use frame pointers) - you can set these switches in the project settings or by using a pragma in your source code (for instance #pragma optimize("gsy", on) ). Additionally you can use merge optimization to merge the .rdata, .text and .reloc sections (need to look up the pragma for those).

There's more you can such as using small /ALIGN and FILEALIGN directives, etc.

Hope that's enough to get you started,

Cheers, Florent

[Charles Pegge]

The web seems to be rather thin on the subject but this article might also help.
(2008)

http://www.catch22.net/tuts/minexe

Charles

[Florent Heyworth]

Here's a version of your Hudplus.exe demo VC++ executable optimized for size (attached). I had a look at Charles Pegge's link and the optimizations posted there look good - although I'm not sure about his ALIGN and FILEALIGN directives which may result in the loader not recognizing the file as a valid executable (YMMV) (not even sure if FILEALIGN is still supported). I wouldn't bother with the .reloc section on second thought because I don't think MSVC 10 will allow it

Florent

[Theo Gottwald]

I didn't start this thread to compare the merits of each compiler.

I did not want to say that you did so, Patrice  .
I just used the chance, to put focus of people on "what really influences the decision for a compiler".

Size and Speed were in the past most interesting.

It's still interesting for many if us, but majority of people just want "get quick from A to B".
And they want it to look "modern". (About this you are the right person to ask :-))

[Patrice Terrier]

Florent--

The size of 26Kb is very good, however i couldn't get it to work by me.
Would it be possible for you to send me the whole project, to let me see what could be wrong with it.


Charles--

I'll check your link asap.



Thanks both of you.

...

[Florent Heyworth]

Florent--

The size of 26Kb is very good, however i couldn't get it to work by me.
Would it be possible for you to send me the whole project, to let me see what could be wrong with it.


Charles--

I'll check your link asap.



Thanks both of you.

...

Hi Patrice

I can send you the project this evening - I don't have it on the machine I'm on at present. The EXE should just work provided all dependencies (dlls such as GDImage.dll, etc and resources - basically all DLLs, sks file and resource folders that are in your DEBUG folder are included in its path). I think that may be the problem you're having with the EXE not working - I take it it's just starting and then immediately closing?

Cheers, Florent

[Patrice Terrier]

Here are a few things that helped me to reduce the size of the C++ HUDplus project EXE.

Using #pragma optimize("gsy", on) decrease the size from 92 Kb down to 87 Kb.

Replacing the C++ standard function sprintf with the SDK API wsprintf decrease the size from 87 Kb down to 76 Kb.



I shall try to replace more of C++ functions with their native Win32 counterparts and see how much i can further reduce the size.

...

[Florent Heyworth]

Hi Patrice

here's the solution for reference, cheers, Florent

[Patrice Terrier]

Florent

Does it work by you?

I mean, when you copy the Release 26 Kb EXE into the Debug folder (where there are the resources) do you see the skinned interface with the Naavi?

...