Delphi XE2 compiled VCL Win32 EXE size

[JJ]

It's freaking 1.6MB for an empty form when using Release build.
I already turned off the Assertion compiler directive, but the size
difference is very small.
Are there more compiler options can I use to decrease the size more?

[Jamie]

Post by JJ
It's freaking 1.6MB for an empty form when using Release build.
I already turned off the Assertion compiler directive, but the size
difference is very small.
Are there more compiler options can I use to decrease the size more?

Isn't that nice :)

I can get very close running results with Lazarus (free Pascal)

Kind of makes you wonder what compiler they are using?

Jamie

[Graeme Geldenhuys]

Post by Jamie
I can get very close running results with Lazarus (free Pascal)

With FPC 2.6.0 and the fpGUI Toolkit I get the following:

820Kb on 64-bit FreeBSD
600Kb on 32-bit FreeBSD

:)

With a three pass optimisation I should be able to shave about another
100Kb or so off those sizes. Funny thing is, with FPC 2.7.1 (trunk) I
get slightly smaller executables.

In the case of fpGUI the executable size is not linear. I can now add
buttons, labels, edits etc to that executable, and the size will hardly
grow.

It is inevitable that with time - as more features get added to a frame
- the size of executables with grow. But jumping by Mb's at a time is a
sign of too much cross-dependencies, or a smartlinker that doesn't work
well.

Regards,
- Graeme -

[Jamie]

Post by Graeme Geldenhuys

Post by Jamie
I can get very close running results with Lazarus (free Pascal)

820Kb on 64-bit FreeBSD
600Kb on 32-bit FreeBSD
:)
With a three pass optimisation I should be able to shave about another
100Kb or so off those sizes. Funny thing is, with FPC 2.7.1 (trunk) I
get slightly smaller executables.
In the case of fpGUI the executable size is not linear. I can now add
buttons, labels, edits etc to that executable, and the size will hardly
grow.
It is inevitable that with time - as more features get added to a frame
- the size of executables with grow. But jumping by Mb's at a time is a
sign of too much cross-dependencies, or a smartlinker that doesn't work
well.
Regards,
- Graeme -

something tells me that support tools like Lazarus may not be
linking correctly.
I say this because I ran a test and placed a Const string in a unit
and then I used that unit in 2 project units.

IN each project unit I made changes to the string, that unit saw the
changes with no problem however, the other unit didn't see it and visa
versa..

That only tells me that some how, each project unit is linking in a
another copy of the same test unit containing a const string of the same
content.

I just updated the other day so I can run another test on that to see
if it is still there. I know the version I was playing with seem to have
all kinds of compiling errors on code that compiled just fine on the
prior version.

Not sure where the breakage is since I was using Lazaruz and not using
FP directly. something tells me that maybe Lazarus has their own custom
version of FP ?

Jamie

[Graeme Geldenhuys]

Post by Jamie
That only tells me that some how, each project unit is linking in a
another copy of the same test unit containing a const string of the same
content.

No, it tells me that that unit wasn't in a shared Lazarus Package. So
each project compiled that unit as if it belongs to the respective
project. Thus each project uses a different Unit Output Directory (where
the *.ppu files go).

It's not a bug, you simply seem to struggle understanding "unit output
directories" and Lazarus Packages (*.lpk files).

Post by Jamie
maybe Lazarus has their own custom version of FP ?

No they don't.


Regards,
- Graeme -

[Marco van de Voort]

Post by JJ
It's freaking 1.6MB for an empty form when using Release build.

I just did the same on an empty form in Delphi XE3:

2,283,008 Project2.exe

[JJ]

Post by Marco van de Voort

Post by JJ
It's freaking 1.6MB for an empty form when using Release build.

2,283,008 Project2.exe

I just found out that the Vcl.Themes unit is the largest portions of the
application code+data in comparison with other used units based on a
generated Segment map file. It's used even though the Runtime Theme is
set to None. I guess they made the code a permanent part of VCL
regardless of that setting.

I don't have XE3 (yet). Could you make a Segment map of an empty VCL
project (Win32 release build) and post it to pastebin.com? I'm curious of
which unit has the largest increase of code+data in comparison with XE2.

[Marco van de Voort]

Post by JJ

Post by Marco van de Voort

Post by JJ
It's freaking 1.6MB for an empty form when using Release build.

2,283,008 Project2.exe

I just found out that the Vcl.Themes unit is the largest portions of the
application code+data in comparison with other used units based on a
generated Segment map file. It's used even though the Runtime Theme is
set to None. I guess they made the code a permanent part of VCL
regardless of that setting.

Possibly owner drawn parts depend on it no matter what is configured since
these have no default look drawn by the OS?

Post by JJ
I don't have XE3 (yet). Could you make a Segment map of an empty VCL
project (Win32 release build) and post it to pastebin.com? I'm curious of
which unit has the largest increase of code+data in comparison with XE2.

Done http://pastebin.com/WcwsP7Cn

[Jamie]

Post by Marco van de Voort

Post by JJ

Post by Marco van de Voort

Post by JJ
It's freaking 1.6MB for an empty form when using Release build.

2,283,008 Project2.exe

I just found out that the Vcl.Themes unit is the largest portions of the
application code+data in comparison with other used units based on a
generated Segment map file. It's used even though the Runtime Theme is
set to None. I guess they made the code a permanent part of VCL
regardless of that setting.

Possibly owner drawn parts depend on it no matter what is configured since
these have no default look drawn by the OS?

Post by JJ
I don't have XE3 (yet). Could you make a Segment map of an empty VCL
project (Win32 release build) and post it to pastebin.com? I'm curious of
which unit has the largest increase of code+data in comparison with XE2.

Done http://pastebin.com/WcwsP7Cn

Removing support for themes to reduce the size of the EXE isn't that
easy actually, like a lot of other VCL code that is used in classes with
a selection of a property.

THe code for example in forms, already have references to the unit
even though they make no use of it. The compiler see's this and simply
must link it in because code has been generated to make references to
functions/class members.

In order to not have this happen, I would guess that a dynamic link
could be used and virtual methods could be assign in the classes to use
this code. This way minimum code will remain in your final EXE.

Other than that, different versions of the VCL would need to be
selected per project to avoid all that linking. Maybe what we need is
several VCL lib paths a project can use. Light weigh, medium and heavy!

I do not have any of the compilers since Borland drop the bomb and
allowed those other guys (no names here) to turn it into a set of
bloated tools.

:)

Jamie

[Marco van de Voort]

Post by Jamie

Post by Marco van de Voort
Done http://pastebin.com/WcwsP7Cn

Removing support for themes to reduce the size of the EXE isn't that
easy actually, like a lot of other VCL code that is used in classes with
a selection of a property.

I know how smartlinking works ;-)

http://stackoverflow.com/questions/4519726/delphi-which-are-the-downsides-of-having-unused-units-listed-in-the-uses-clause/4519894#4519894

But that doesn't mean it couldn't be minimized. The question is more if
anybody cares enough to do so, IOW where is the real problem?

Post by Jamie
THe code for example in forms, already have references to the unit
even though they make no use of it. The compiler see's this and simply
must link it in because code has been generated to make references to
functions/class members.
In order to not have this happen, I would guess that a dynamic link
could be used and virtual methods could be assign in the classes to use
this code. This way minimum code will remain in your final EXE.

No. Dynamic linking/packages doesn't really solve anything. It only
fragments the units over multiple binaries.

Anything like that can also be done on the unit level (with minimal
abstract base classes and the real thing only kicking in if you use
certain units that register the derived classes with all the code
and depedencies).

See e.g. how Free Pascal handles similar problems on RTL level to
keep thread and localisation support out of the binary on *nix.
(cthreads/clocale). Though that is more because of dependencies/deployment
than binary sizes.

Post by Jamie
Other than that, different versions of the VCL would need to be
selected per project to avoid all that linking. Maybe what we need is
several VCL lib paths a project can use. Light weigh, medium and heavy!

Sounds like a canon to shoot a mosquito.

Post by Jamie
I do not have any of the compilers since Borland drop the bomb and
allowed those other guys (no names here) to turn it into a set of
bloated tools.

"bloat" is so horribly subjective. As said, most people see no problem
in wasting ten times the space due to browser caches.

So why should Embarcadero spend a significant percentage of their
development budget on this? Better they start fixing bugs with it :)

[Jamie]

Post by Marco van de Voort

Post by Jamie

Post by Marco van de Voort
Done http://pastebin.com/WcwsP7Cn

Removing support for themes to reduce the size of the EXE isn't that
easy actually, like a lot of other VCL code that is used in classes with
a selection of a property.

I know how smartlinking works ;-)
http://stackoverflow.com/questions/4519726/delphi-which-are-the-downsides-of-having-unused-units-listed-in-the-uses-clause/4519894#4519894
But that doesn't mean it couldn't be minimized. The question is more if
anybody cares enough to do so, IOW where is the real problem?

Post by Jamie
THe code for example in forms, already have references to the unit
even though they make no use of it. The compiler see's this and simply
must link it in because code has been generated to make references to
functions/class members.
In order to not have this happen, I would guess that a dynamic link
could be used and virtual methods could be assign in the classes to use
this code. This way minimum code will remain in your final EXE.

No. Dynamic linking/packages doesn't really solve anything. It only
fragments the units over multiple binaries.
Anything like that can also be done on the unit level (with minimal
abstract base classes and the real thing only kicking in if you use
certain units that register the derived classes with all the code
and depedencies).
See e.g. how Free Pascal handles similar problems on RTL level to
keep thread and localisation support out of the binary on *nix.
(cthreads/clocale). Though that is more because of dependencies/deployment
than binary sizes.

Post by Jamie
Other than that, different versions of the VCL would need to be
selected per project to avoid all that linking. Maybe what we need is
several VCL lib paths a project can use. Light weigh, medium and heavy!

Sounds like a canon to shoot a mosquito.

Post by Jamie
I do not have any of the compilers since Borland drop the bomb and
allowed those other guys (no names here) to turn it into a set of
bloated tools.

"bloat" is so horribly subjective. As said, most people see no problem
in wasting ten times the space due to browser caches.
So why should Embarcadero spend a significant percentage of their
development budget on this? Better they start fixing bugs with it :)

Why? so I can use memory that isn't needed by an app of such nature
for other things.

You know the term multitasking? It means that you can run multiple
different apps on your PC with out running out of resources..

And for the comment I made with dynamic code, I wasn't referring to
Packages, I was referring to a standard non-delphi DLL that could be
loaded at run time at will if only the selective property or flag is
set, then from there, a few call backs or what ever is needed to make
access to the main body functions, which are in the DLL. This
would be a choice that could be made on resource usage at run time.

Packages in delphi aren't much better in the way the code implements
them in the main program. The code in the main program is still making
references to all sorts of things that would be in a package and on top
of that, most people put a lot more than a single unit's worth of code
in a package.

So in the end, the final program will still load that package in the
case of the themes unit.

you can load packages like a raw DLL but I don't see any of the VCL
code organized to allow this to where it actually pays off.

I am thinking of writing a SDR (sound defined radio) program using
the latest version of Lazarus. Recent testing shows that it is running
neck and neck with current version of delpi. If I didn't know any
better, it looks like they are using FP compiler? Something is up with
that..

Jamie

[Marco van de Voort]

Post by Jamie

Post by Marco van de Voort
So why should Embarcadero spend a significant percentage of their
development budget on this? Better they start fixing bugs with it :)

Why? so I can use memory that isn't needed by an app of such nature
for other things.

EXEs are only memory mapped, and not the whole binary must be in memory.
Unused parts are unloaded in low memory circumstances. (though with 4k
granularity for 32-bit and 8k for 64-bit).

Moreover, for most non trivial applications, datasize allocated by an EXE
dwarfs the code size. If you persist in that way of thinking, I think the
growing of TObject in post D2007 versions might be a much worse thing that
dwarfs binary size issues.

Post by Jamie
You know the term multitasking? It means that you can run multiple
different apps on your PC with out running out of resources..

Yes. And I fail to see how a 300kb difference will make a difference
in a world where entry level machines are equiped with at least 4GB memory.

Post by Jamie
And for the comment I made with dynamic code, I wasn't referring to
Packages, I was referring to a standard non-delphi DLL that could be
loaded at run time at will if only the selective property or flag is
set, then from there, a few call backs or what ever is needed to make
access to the main body functions, which are in the DLL. This
would be a choice that could be made on resource usage at run time.

The result remains the same. It is the refactoring into a minimal interface
and the full implementation that causes the savings. Not the dyn
usage itself.

If such refactoring was done, Embarcadero could have simply only link
the bulk of the code in when needed.

Post by Jamie
Packages in delphi aren't much better in the way the code implements
them in the main program. The code in the main program is still making
references to all sorts of things that would be in a package and on top
of that, most people put a lot more than a single unit's worth of code
in a package.

That is not true. Packages can also be dynloaded, specially if they
override base types that are statically linked.

Packages are the same as dyn linking in most ways, just under control
of the compiler.

Post by Jamie
So in the end, the final program will still load that package in the
case of the themes unit.

If you only put the themes unit in the package. BUt if the RTL contains
an abstract themes, you could load the full version of themes dynamically,
theoretically.

Post by Jamie
you can load packages like a raw DLL but I don't see any of the VCL
code organized to allow this to where it actually pays off.

That's the exact point I tried to make in the dynamic library package.
The organization for minimalistic purposes isn't there. And then
it doesn't matter if it is statically or dynamically linked.

But afaik Delphi allows recompilation of the RTL/VCL? Simply cut out
themes, turn extended RTTI off?

Post by Jamie
I am thinking of writing a SDR (sound defined radio) program using
the latest version of Lazarus. Recent testing shows that it is running
neck and neck with current version of delpi. If I didn't know any
better, it looks like they are using FP compiler? Something is up with
that..

Lazarus uses fpc yes, always has, the projects have been linked since
Lazarus' inception. (FPC is older)

But Lazarus has binary size overhead due to its multiplatformness, and
is slowly increasing too.

[JJ]

... Maybe what we need is
several VCL lib paths a project can use. Light weigh, medium and heavy!

That's what I did with my Delphi7 RTL. I stripped it down to minimum and
keep the string routines. I need it for delphi-wrapped assembly programs
with assembly as the dominant language.

[Jamie]

Post by JJ

... Maybe what we need is
several VCL lib paths a project can use. Light weigh, medium and heavy!

That's what I did with my Delphi7 RTL. I stripped it down to minimum and
keep the string routines. I need it for delphi-wrapped assembly programs
with assembly as the dominant language.

You sound like a real coder!

Jamie

[JJ]

Post by Marco van de Voort
Possibly owner drawn parts depend on it no matter what is configured
since these have no default look drawn by the OS?

I think so too.

Post by Marco van de Voort
Done http://pastebin.com/WcwsP7Cn

Is RTTI enabled in that build or is it explicitly used in XE3? 280k is used
for System.Rtti and it's not used in XE2.
System.Classes alone is 256k larger in XE3, 3 times larger.
The remaining 64k increase are spread to other units.

My XE2 map: http://pastebin.com/5zgCrEsE
My config: http://pastebin.com/bz3ysGsQ

[Marco van de Voort]

Post by JJ

Post by Marco van de Voort
Possibly owner drawn parts depend on it no matter what is configured
since these have no default look drawn by the OS?

I think so too.

Post by Marco van de Voort
Done http://pastebin.com/WcwsP7Cn

Is RTTI enabled in that build or is it explicitly used in XE3? 280k is used

It's off.

Post by JJ
System.Classes alone is 256k larger in XE3, 3 times larger.
The remaining 64k increase are spread to other units.

No idea. I don't have XE2 installed anywhere, so I can't really compare what
makes the difference.

[Rudy Velthuis (TeamB)]

Post by JJ
It's freaking 1.6MB for an empty form when using Release build.
I already turned off the Assertion compiler directive, but the size
difference is very small.
Are there more compiler options can I use to decrease the size more?

Turn of RTTI generation. The built-in help explains how to do that. The
online docwiki page is a copy of the built-in help:

http://docwiki.embarcadero.com/RADStudio/XE3/en/RTTI_directive_%28Delphi%29

IOW, you can use

{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}

in your source files to turn off all RTTI.

[Marco van de Voort]

Post by Rudy Velthuis (TeamB)

Post by JJ
It's freaking 1.6MB for an empty form when using Release build.
I already turned off the Assertion compiler directive, but the size
difference is very small.
Are there more compiler options can I use to decrease the size more?

Turn of RTTI generation. The built-in help explains how to do that. The

Doesn't seem to make a difference for empty form size.

[Rudy Velthuis (TeamB)]

Post by Rudy Velthuis (TeamB)

Post by JJ
It's freaking 1.6MB for an empty form when using Release build.
I already turned off the Assertion compiler directive, but the

size >> difference is very small.

Post by Rudy Velthuis (TeamB)

Post by JJ
Are there more compiler options can I use to decrease the size

more?

Post by Rudy Velthuis (TeamB)
Turn of RTTI generation. The built-in help explains how to do that.

Doesn't seem to make a difference for empty form size.

Hmmm... indeed.

[Rudy Velthuis (TeamB)]

Post by Rudy Velthuis (TeamB)

wrote: >> It's freaking 1.6MB for an empty form when using Release
build. >> I already turned off the Assertion compiler directive,
but the size >> difference is very small.

Post by Rudy Velthuis (TeamB)

Post by JJ
Are there more compiler options can I use to decrease the size

more?

Post by Rudy Velthuis (TeamB)
Turn of RTTI generation. The built-in help explains how to do

Doesn't seem to make a difference for empty form size.

Hmmm... indeed.

Seems RTTI in the RTL and VCL units will still be compiled in, so you
might have to recompile the RTL and VCL without RTTI too, to get the
absolutely minimum size.

[Marco van de Voort]

Post by Rudy Velthuis (TeamB)

Post by Rudy Velthuis (TeamB)

Post by Marco van de Voort
more?

Post by Rudy Velthuis (TeamB)
Turn of RTTI generation. The built-in help explains how to do

Doesn't seem to make a difference for empty form size.

Hmmm... indeed.

Seems RTTI in the RTL and VCL units will still be compiled in, so you
might have to recompile the RTL and VCL without RTTI too, to get the
absolutely minimum size.

Yup, and while at it, you can probably cut down other excess bagage too,
if it matters so much.

It might be a good idea for FPC though, instead of an unit local directive
that just suspends RTTI generation, have a global switch that works at the
linker level. Requires an internal link though....

[JJ]

Post by Rudy Velthuis (TeamB)
Turn of RTTI generation. The built-in help explains how to do that.
http://docwiki.embarcadero.com/RADStudio/XE3/en/RTTI_directive_%28Delph
i%29

The "Emit runtime type information" project option is already disabled in
my build.

Post by Rudy Velthuis (TeamB)
IOW, you can use
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
in your source files to turn off all RTTI.

Adding that line into the DPR and the unit also has no effect.

But adding "{$WEAKLINKRTTI ON}" can decrease the size from 1.6MB to
1.4MB. Can this directive affect code functionality or performance?

[Rudy Velthuis (TeamB)]

Post by JJ
But adding "{$WEAKLINKRTTI ON}" can decrease the size from 1.6MB to
1.4MB. Can this directive affect code functionality or performance?

Only if you use RTTI.

[Marco van de Voort]

Post by Rudy Velthuis (TeamB)

Post by JJ
But adding "{$WEAKLINKRTTI ON}" can decrease the size from 1.6MB to
1.4MB. Can this directive affect code functionality or performance?

Only if you use RTTI.

XE3 drops to 1.9MB.