Size of program executable very big...

[Bo Berglund]

My test program contains a simple form with a few buttons and
comboboxes and a memo. Additionally I have a unit defining a
communications class, which uses SdpoSerial.

I had not looked at the size before but now I see that the test
executable is now 13 Mbytes! Is this normal? I would not have expected
this size considering that the program contains so little yet...

I use FPC 2.4.2 and Lazarus fixes_0_9_30 and SdpoSerial 0.1.4 on
Windows XP.


Bo Berglund


--

[Michael Schneider]

Post by Bo Berglund
I had not looked at the size before but now I see that the test
executable is now 13 Mbytes! Is this normal? I would not have expected
this size considering that the program contains so little yet...

http://wiki.lazarus.freepascal.org/Size_Matters

--

[Bo Berglund]

On Thu, 17 Feb 2011 00:36:48 +0100, Michael Schneider

Post by Michael Schneider

Post by Bo Berglund
I had not looked at the size before but now I see that the test
executable is now 13 Mbytes! Is this normal? I would not have expected
this size considering that the program contains so little yet...

http://wiki.lazarus.freepascal.org/Size_Matters

Trying to digest but very hard...
Isn't there a simpler setting in Lazarus that can switch on/off
optimization or debug data generation?
I guess that the exe is big because it contains debug stuff, but that
a single form created as a default project and where I added 10
buttons, 3 spinedits, 1 combobox and 5 shapes as signal "lamps" plus a
couple of units with pretty straightforward object definitions and the
SdpoSerial component could turn out as a 13 Mb exe file is beyond my
grasp.
THe link above brings me to a page where big seems to start at 6
Mb....

[Frank Church]

Post by Bo Berglund
On Thu, 17 Feb 2011 00:36:48 +0100, Michael Schneider

Post by Michael Schneider

Post by Bo Berglund
I had not looked at the size before but now I see that the test
executable is now 13 Mbytes! Is this normal? I would not have expected
this size considering that the program contains so little yet...

http://wiki.lazarus.freepascal.org/Size_Matters

Trying to digest but very hard...
Isn't there a simpler setting in Lazarus that can switch on/off
optimization or debug data generation?
I guess that the exe is big because it contains debug stuff, but that
a single form created as a default project and where I added 10
buttons, 3 spinedits, 1 combobox and 5 shapes as signal "lamps" plus a
couple of units with pretty straightforward object definitions and the
SdpoSerial component could turn out as a 13 Mb exe file is beyond my
grasp.
THe link above brings me to a page where big seems to start at 6
Mb....

'strip --strip-all programname.exe' when you are ready to deliver.

There are other optimizations that can be used in the code generation itself

Post by Bo Berglund
--
Bo Berglund
Developer in Sweden
--
_______________________________________________
Lazarus mailing list
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

[Graeme Geldenhuys]

Post by Bo Berglund

Post by Michael Schneider
http://wiki.lazarus.freepascal.org/Size_Matters

Trying to digest but very hard...

Yes, size is dependent on debug information and smartlinking. To make
your executables smaller you have a few options:

1) Strip debug information and enable smart linking.
Project Options -> Code generation
project Options -> Linking.

The FPC parameters are:
-CX -XX -Xs

2) Use a "lighter" GUI toolkit. fpGUI produces much smaller executables
than LCL (handy for embedded work). MSEgui is somewhere in the
middle.


I must add in LCL's defence... A simple application might end up having
a 10MB executable, but then it grows very slowly from there. If you have
to plot the executable size dependant on the size of the application,
the growth is NOT linear.



Regards,
- Graeme -

[Bo Berglund]

On Fri, 18 Feb 2011 08:46:45 +0200, Graeme Geldenhuys

Post by Graeme Geldenhuys
I must add in LCL's defence... A simple application might end up having
a 10MB executable, but then it grows very slowly from there. If you have
to plot the executable size dependant on the size of the application,
the growth is NOT linear.

Yes I know about this non-linear behaviour from Delphi. But it started
at a much lower fixed size. BTW we always compiled only for a single
exe in Delphi, so the concept of runtime libraries are not confusing
this comparison.

[Bo Berglund]

On Fri, 18 Feb 2011 08:46:45 +0200, Graeme Geldenhuys

Post by Graeme Geldenhuys
1) Strip debug information and enable smart linking.
Project Options -> Code generation
project Options -> Linking.
-CX -XX -Xs
2) Use a "lighter" GUI toolkit. fpGUI produces much smaller executables
than LCL (handy for embedded work). MSEgui is somewhere in the
middle.

Couldn't Lazarus be "smart" about the code generation as follows:
1) When one clicks the run button (green arrow) lazarus creates the
exe file with embedded debug information such that breakpoints etc
work for debugging.

2) When one uses the build function Lazarus does NOT use the compile
option to enter debug data into the exe, thus creating the slimmer
file.

With this one would get the best of both worlds, right?

[Graeme Geldenhuys]

Post by Bo Berglund
With this one would get the best of both worlds, right?

I'm pretty sure with Lazarus' new "build modes" this is probably
possible already. I haven't played with that feature yet, so I can't
give a definitive answer.

Alternatively, you can also tell Lazarus/FPC to generate an external
file (not part of the executable) for the debug information. Thus you
have a small executable, and a separate file that contains the debugging
info. GDB will then look at both for debugging support. Again, not
something I tried myself yet, but have heard of others that use it like
this.


Regards,
- Graeme -

[Mattias Gaertner]

 

Post by Bo Berglund
[...]
1) When one clicks the run button (green arrow) lazarus creates the
exe file with embedded debug information such that breakpoints etc
work for debugging.
2) When one uses the build function Lazarus does NOT use the compile
option to enter debug data into the exe, thus creating the slimmer
file.
With this one would get the best of both worlds, right? 

No, that would be a bug. "Compile" let the compiler compile all new, "Build"
recompiles all units of the project.
 
You can define a second build mode "release" and enable whatever optimization
you think is appropriate for your customers. 
 

Mattias 

[Paul van Helden]

The "Use external gdb debug symbol file (-Xg)" linking option works well for
me. It creates a 30MB .dbg file and a 5.4MB executable for my current
project.

With this set, the "strip symbols from executable (-Xs)" option has no
impact and unchecking the -gl option only shaves of 6KB!

Post by Mattias Gaertner
No, that would be a bug. "Compile" let the compiler compile all new,
"Build" recompiles all units of the project.

When I click Run, a lot of untouched units are recompiled every time... What
exactly is the difference between "Run", "Build", "Build all" and "Quick
compile"?

When I do a "build all", it takes 10 seconds for my project. Then I touch an
insignificant unit and most, but not all, units are recompiled. 6 seconds.
"Quick compile" and "Build" seem to be doing the same as "Run" (without
running of course).

Post by Mattias Gaertner
You can define a second build mode "release" and enable whatever
optimization you think is appropriate for your customers.
This is a great new feature.

Regards,

Paul.

[Bo Berglund]

On Fri, 18 Feb 2011 13:37:39 +0200, Paul van Helden

Post by Paul van Helden
The "Use external gdb debug symbol file (-Xg)" linking option works well for
me. It creates a 30MB .dbg file and a 5.4MB executable for my current
project.
With this set, the "strip symbols from executable (-Xs)" option has no
impact and unchecking the -gl option only shaves of 6KB!

That is probably what I will try tonight then. Seems reasonable to me.

[Bo Berglund]

On Fri, 18 Feb 2011 14:35:31 +0100, Bo Berglund

Post by Bo Berglund
On Fri, 18 Feb 2011 13:37:39 +0200, Paul van Helden

Post by Paul van Helden
The "Use external gdb debug symbol file (-Xg)" linking option works well for
me. It creates a 30MB .dbg file and a 5.4MB executable for my current
project.
With this set, the "strip symbols from executable (-Xs)" option has no
impact and unchecking the -gl option only shaves of 6KB!

That is probably what I will try tonight then. Seems reasonable to me.

With this option on the exe file reduced from 13 Mb to 1.6 Mb! :-)
Thanks!

[Mattias Gaertner]

On Fri, 18 Feb 2011 13:37:39 +0200

Post by Paul van Helden
The "Use external gdb debug symbol file (-Xg)" linking option works well for
me. It creates a 30MB .dbg file and a 5.4MB executable for my current
project.
With this set, the "strip symbols from executable (-Xs)" option has no
impact and unchecking the -gl option only shaves of 6KB!

Post by Mattias Gaertner
No, that would be a bug. "Compile" let the compiler compile all new,
"Build" recompiles all units of the project.

When I click Run, a lot of untouched units are recompiled every time... What
exactly is the difference between "Run", "Build", "Build all" and "Quick
compile"?

Yes, sorry for the fuzz.
Run checks if something changed and invokes a "Build". Then start
program or debugger.
Build calls compiler.
Build all calls compiler with -B.
Quick compile calls compiler with options to omit assembling and
linking.

Post by Paul van Helden
When I do a "build all", it takes 10 seconds for my project. Then I touch an
insignificant unit and most, but not all, units are recompiled. 6 seconds.

Maybe linking your program takes a few seconds.

Post by Paul van Helden
"Quick compile" and "Build" seem to be doing the same as "Run" (without
running of course).

Post by Mattias Gaertner
You can define a second build mode "release" and enable whatever
optimization you think is appropriate for your customers.
This is a great new feature.

:)

Mattias

--

[Paul van Helden]

Post by Mattias Gaertner

Post by Paul van Helden
When I click Run, a lot of untouched units are recompiled every time...

What

Post by Paul van Helden
exactly is the difference between "Run", "Build", "Build all" and "Quick
compile"?

Yes, sorry for the fuzz.
Run checks if something changed and invokes a "Build". Then start
program or debugger.
Build calls compiler.
Build all calls compiler with -B.
Quick compile calls compiler with options to omit assembling and
linking.

Post by Paul van Helden
When I do a "build all", it takes 10 seconds for my project. Then I touch

an

Post by Paul van Helden
insignificant unit and most, but not all, units are recompiled. 6

seconds.
Maybe linking your program takes a few seconds.

I have found the cause! Some months ago I started outputting the .o and .ppu
files into a subdirectory. Ever since, for each unit that had an old .o and
.ppu in the main directory, Build would recompile it. This caused a
recompile of more than half of all my code every time I ran the project (if
there had been a change).

Now everything makes a lot more sense.

* Run will invoke Build if a change has been detected to the source. (Some
source file with a later date than ProjectName.compiled or ProjectName.exe?)
* Build recompiles all units with source files that are newer than their
object files (but looks in the main directory first for the object files)
and of course any other dependent units if needed. (When any compiler
switches were changed, Build All is invoked instead?).
* Build All recompiles all used units regardless.
* Quick compile does a Build without linking.

I'm sure the above summary could be improved upon.

Regards,

Paul.

[waldo kitty]

Post by Mattias Gaertner

Post by Bo Berglund
[...]
1) When one clicks the run button (green arrow) lazarus creates the
exe file with embedded debug information such that breakpoints etc
work for debugging.
2) When one uses the build function Lazarus does NOT use the compile
option to enter debug data into the exe, thus creating the slimmer
file.
With this one would get the best of both worlds, right?

No, that would be a bug. "Compile" let the compiler compile all new, "Build"
recompiles all units of the project.
You can define a second build mode "release" and enable whatever optimization
you think is appropriate for your customers.

i recently ran into this in plain FPC when i switched from DEBUG to RELEASE mode
and had to re-enter the unit and include directories the project i'm working on
needed... it was a bit of a shock to have them "lost" when switching modes but a
quick look in the fpc.cfg showed me the problem :) no clue if this also applies
to lazarus, though... i've not even attempted to use laz's graphical environment
for this particular console only tool build...

--

[Mattias Gaertner]

On Fri, 18 Feb 2011 20:54:29 -0500

Post by waldo kitty
[...]

Post by Mattias Gaertner
You can define a second build mode "release" and enable whatever optimization
you think is appropriate for your customers.

i recently ran into this in plain FPC when i switched from DEBUG to RELEASE mode
and had to re-enter the unit and include directories the project i'm working on
needed... it was a bit of a shock to have them "lost" when switching modes but a
quick look in the fpc.cfg showed me the problem :) no clue if this also applies
to lazarus, though... i've not even attempted to use laz's graphical environment
for this particular console only tool build...

When you create a new build mode in Lazarus the current one is copied.

When you add unit paths, they are not automatically copied to the other
build modes. There is a dialog showing the differences between the build
modes.


Mattias

--

[Hans-Peter Diettrich]

Post by Mattias Gaertner
When you create a new build mode in Lazarus the current one is copied.

Why that?

When I want to maintain different branches of a project, I can already
save the project under a new name. But IMO Release and Debug versions
only should change compiler options, not the units.

DoDi


--

[Mattias Gaertner]

On Sat, 19 Feb 2011 13:15:28 +0100

Post by Hans-Peter Diettrich

Post by Mattias Gaertner
When you create a new build mode in Lazarus the current one is copied.

Why that?

Because normally you want to change only a few things like optimization
flags and keep the rest (e.g. search paths, target file name,
verbosity, ...).

Post by Hans-Peter Diettrich
When I want to maintain different branches of a project, I can already
save the project under a new name. But IMO Release and Debug versions
only should change compiler options, not the units.

I can't follow you here. Why should build modes change units?

Mattias

--

[Hans-Peter Diettrich]

Post by Mattias Gaertner

Post by Hans-Peter Diettrich

Post by Mattias Gaertner
When you create a new build mode in Lazarus the current one is copied.

Why that?

Because normally you want to change only a few things like optimization
flags and keep the rest (e.g. search paths, target file name,
verbosity, ...).

The *rest* is of my concern. It should not be copied, instead be used as
is, in every mode.

What fun when you debug a new version, and then ship the old one, built
from the old release build mode :-(

DoDi


--

[Mattias Gaertner]

On Sat, 19 Feb 2011 23:05:14 +0100

Post by Hans-Peter Diettrich

Post by Mattias Gaertner

Post by Hans-Peter Diettrich

Post by Mattias Gaertner
When you create a new build mode in Lazarus the current one is copied.

Why that?

Because normally you want to change only a few things like optimization
flags and keep the rest (e.g. search paths, target file name,
verbosity, ...).

The *rest* is of my concern. It should not be copied, instead be used as
is, in every mode.
What fun when you debug a new version, and then ship the old one, built
from the old release build mode :-(

Ehm, maybe you misunderstood the term "build mode" in
Lazarus?

http://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Build_modes

Mattias

--

[waldo kitty]

Post by Hans-Peter Diettrich

Post by Mattias Gaertner
When you create a new build mode in Lazarus the current one is copied.

Why that?
When I want to maintain different branches of a project, I can already save the
project under a new name. But IMO Release and Debug versions only should change
compiler options, not the units.

i kinda wondered the same thing... but then i thought about it a little more and
realized that one could have "debug" units and include files that are the same
as the release ones but without the debug stuff included...

another thing is do you really want to rebuild everything in your project when
switching modes and including (or not) all the additional debug info?

yes, i know the above could easily be handled with a define but not everyone
thinks or operates the same way ;)

--

[leledumbo]

Post by Bo Berglund
With this one would get the best of both worlds, right?

Nope, some people does debugging externally from command line sometimes
because the need of specific gdb command. Doing so would disallow this
"feature".

[Thomas Gatliff]

You might want to look at the lazarus faq:
http://wiki.lazarus.freepascal.org/Lazarus_Faq

Post by Bo Berglund
My test program contains a simple form with a few buttons and
comboboxes and a memo. Additionally I have a unit defining a
communications class, which uses SdpoSerial.
I had not looked at the size before but now I see that the test
executable is now 13 Mbytes! Is this normal? I would not have expected
this size considering that the program contains so little yet...
I use FPC 2.4.2 and Lazarus fixes_0_9_30 and SdpoSerial 0.1.4 on
Windows XP.
Bo Berglund
--
_______________________________________________
Lazarus mailing list
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus