to reduce footprint

[George2]

Hello everyone,


I am wondering how to reduce the footprint of a binary build (C/C++) program generated by gcc.

1. Any ideas of reduce the footprint of a debug version build?
2. Any ideas of reduce the footprint of a release version build?

I think some linker or compiler options may help, what are they? Any other ideas to reduce footprint?


thanks in advance,
George

[dcjr84]

There may be some compiler optimization options to do so (at least for release build).

But I would imagine if there are, then they are compiler dependent.

Meaning, you would need to consult your gcc documentation for such options.

I am not sure where you might find that, but I am sure google can help

[UnderDog]

And remember the tradeoffs. So e.g. my VC compiler gives me options such as

1. Optimise for speed
2. Optimise for size
3. Then there is a option to do 'balanced' optimisation.

There are two options because when you optimization for speed MAY result in increased size and vice versa.

There there are following kind of options

1. Maintain single copy of duplicate strings
2. Remove functions that not called anywaher

Then some more that can affect code size

1. Exception handling model (synchronous/asynchronous)
2. Enabling/Disabling exception handling
3. Enabling/Disabling RTTI

[SuperKoko]

If you want to reduce the executable size (it'll not change the execution speed nor the memory footprint when the program is launched AFAIK), you can use the "strip" tool or pass the "-s" flag to the compiler or linker.

Not using the "-g" flag greatly reduces the executable size, and should be done for release software.

Using optimization level -O2 is a good alternative between speed and code size.
-O0 produces slow, and large code.
-O1 is not very good (it doesn't contain advanced optimizations).
-O3 produces larger executables and may be slower than -O2 sometimes (but you may test).
-Os is ok to optimize for speed.

1. Any ideas of reduce the footprint of a debug version build?

Why?
A simple solution: Compile it as if it were a release version.

[George2]

Any more specific hints, dcjr84?

There may be some compiler optimization options to do so (at least for release build).

But I would imagine if there are, then they are compiler dependent.

Meaning, you would need to consult your gcc documentation for such options.

I am not sure where you might find that, but I am sure google can help

regards,
George

[George2]

Thank you UnderDog! I agree with all of your below ideas. Do you have any more ideas of compiler/linker option level?

And remember the tradeoffs. So e.g. my VC compiler gives me options such as

1. Optimise for speed
2. Optimise for size
3. Then there is a option to do 'balanced' optimisation.

There are two options because when you optimization for speed MAY result in increased size and vice versa.

There there are following kind of options

1. Maintain single copy of duplicate strings
2. Remove functions that not called anywaher

Then some more that can affect code size

1. Exception handling model (synchronous/asynchronous)
2. Enabling/Disabling exception handling
3. Enabling/Disabling RTTI

regards,
George

[TheCPUWizard]

And don't forget to avoid writing bloated code to begin with

[dcjr84]

Any more specific hints, dcjr84?
regards,
George

Yes.

To quote myself...

Meaning, you would need to consult your gcc documentation for such options.

[George2]

Thanks SuperKoko!

If you want to reduce the executable size (it'll not change the execution speed nor the memory footprint when the program is launched AFAIK), you can use the "strip" tool or pass the "-s" flag to the compiler or linker.

I agree. But it will reduce the function to debug.

Not using the "-g" flag greatly reduces the executable size, and should be done for release software.

Very confused. Do you mean -g option for -ld? I found from man page that this option is not supported any more?

Here it is, "-g Ignored. Provided for compatibility with other tools."

http://www.mcsr.olemiss.edu/cgi-bin/man-cgi?ld

Using optimization level -O2 is a good alternative between speed and code size.
-O0 produces slow, and large code.
-O1 is not very good (it doesn't contain advanced optimizations).
-O3 produces larger executables and may be slower than -O2 sometimes (but you may test).
-Os is ok to optimize for speed.

I am interested in reduce footprint. It seems that using -Os can both achieve the better performance and reduce the footprint. Is that correct?

If yes, it is amazing that both size can be reduced the speed is faster. Because I think speed and size are balanced parameters -- if you increase speed, the footprint will be worse (bigger). Any comments?


regards,
George

[George2]

Thanks TheCPUWizard! How to write code which is bloated enough? Seems you are very good at producing bloated code! :-)

And don't forget to avoid writing bloated code to begin with

regards,
George

[George2]

Any more details dcjr84 dude? For example, indicating to me which options? The PDF is too big!

Yes.

To quote myself...

regards,
George

[SuperKoko]

I agree. But it will reduce the function to debug.

Yes, but optimizations of executable sizes are used for releases versions of a project... Except if your HD has less than 1MiB of free room and you want to be able to debug your project.

Very confused. Do you mean -g option for -ld? I found from man page that this option is not supported any more?

The -g option of g++
This option tells g++ that he has to generate debug information.

I am interested in reduce footprint. It seems that using -Os can both achieve the better performance and reduce the footprint. Is that correct?

Sorry, it's a lapsus.
I meant "-Os optimizes for size".

However, -Os both optimize for size and speed! It means : "optimize for size and speed, but, please, don't increase code size".
There are a lot of optimization options that GCC supports.
And there are two categories of optimizations:
Those reducing size and increasing speed (actually, most optimizations).
Those increasing size and increasing speed (when there's enough cache).
(note: AFAIK there is currently no category of optimizations reducing size and not changing or reducing speed)
Very few of these later options exist: Mainly massive and dumb inlining of non-inline functions (in practice, it often increase size, and reduces speed).

The -Ox options are only aliases of lists of optimizations.

-O0 disables all optimizations, including those reducing size and increasing speed. It produces bloated and slow code... But, it compiles faster and a lot of code exposing undefined behavior behaves "well".
-Os includes almost all optimizations reducing size and increasing speed.
-O2 includes all optimizations of -Os, plus a few optimizations that can increase code size by a small factor, and increase speed by a small factor (-falign-functions -falign-jumps -falign-loops -falign-labels -freorder-blocks -freorder-blocks-and-partition -fprefetch-loop-arrays).
So, the difference between -Os and -O2 is typically very slight, and, often, the speed and size differences is not visible.

-O3 includes all optimizations of -O2 plus a few optimizations that bloat code and increase sometimes the speed (but code bloat is so huge that, often it doesn't produce faster code than -O2, and sometimes produce slower code).
It includes: -finline-functions, -funswitch-loops and -fgcse-after-reload

-finline-functions: inline non-inline functions... That's usually dumb, because nowadays, programmers do a better job (perhaps with the help of a profiler) at choosing which functions worth inlining. This option bloats code.
-funswitch-loops: Move branches with loop invariant conditions out of the loop, with duplicates of the loop on both branches (modified according to result of the condition).
Not always a good idea.

If yes, it is amazing that both size can be reduced the speed is faster. Because I think speed and size are balanced parameters -- if you increase speed, the footprint will be worse (bigger). Any comments?

No.
Almost all optimizations ... all the optimizations that finally make your program twice as small and four times faster... All these optimizations greatly reduce size and greatly increase speed.
With -Os, you get all these optimizations.
-O2 is almost identical... It adds a few things that align code at some places and increases size a bit (a few percents) and increase speed a bit (a few percents).
-O3 increases size a lot compared to -O2 and, sometimes increase speed, rarely by a large factor, and, sometimes, reduce speed.

-O1 produces larger & slower code than -Os... But, it compiles faster.
-O0 produces very huge & very slow code.

[George2]

Thanks SuperKoko! Agree with all of your great answers! Two more comments,

1. strip could only apply on debug version binary, agree?


2. For the following statements,

-funswitch-loops: Move branches with loop invariant conditions out of the loop, with duplicates of the loop on both branches (modified according to result of the condition).
Not always a good idea.

Why not always a good idea? I think it is a great idea to move invariable statements inside a loop outside. :-)

Could you show a sample to show why sometimes it is not always a good idea?


regards,
George

[SuperKoko]

Thanks SuperKoko! Agree with all of your great answers! Two more comments,

1. strip could only apply on debug version binary, agree?

No, it applies to release version as well.

2. For the following statements,



Why not always a good idea? I think it is a great idea to move invariable statements inside a loop outside. :-)

If the statements inside the loop body are simple and the condition/iteration-statement are big (for example, iterating through a deque or map or multimap), it may almost double the size of the code of the whole loop, and the benefits will be very small on modern CPU (Pentium & higher) having branch prediction: Typically a single CPU cycle... two CPU cycles in the worst case.

[George2]

Thanks SuperKoko! Merry X'Mas to you in advance!

No, it applies to release version as well.

In my previous understanding, debug version binary contains some symbol tables which debugger could utilize to locate the binary code location by variable/function name defined in source code. And strip will remove such symbol table (which contains the function/variable name) to reduce size. So, I think strip only applies to debug version since release version does not need to have such symbol tables.

It seems I am wrong according to your description above. Could you explain why release version could be smaller if strip is used and what information is removed from release version by strip please?

If the statements inside the loop body are simple and the condition/iteration-statement are big (for example, iterating through a deque or map or multimap), it may almost double the size of the code of the whole loop, and the benefits will be very small on modern CPU (Pentium & higher) having branch prediction: Typically a single CPU cycle... two CPU cycles in the worst case.

I becomes more interested in this topic. Why if the condition/iteration are complex, the code will be larger? I think the condition/iteration is something like a sub-function, which could be re-used each time in a loop cycle. Since it could be re-used, it should not make size that larger. :-)

Could you explain why complex condition/iteration will make code larger please? And why modern CPU can not deal with such issues in an efficient manner?


regards,
George