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]

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]

On 2013-03-12 22:51, Jamie wrote:
> 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 -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

[Jamie]

Graeme Geldenhuys wrote:
> On 2013-03-12 22:51, Jamie wrote:
>
>> 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 -
>

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]

On 2013-03-14 23:32, Jamie wrote:
> 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).

> maybe Lazarus has their own custom version of FP ?

No they don't.


Regards,
- Graeme -

[Marco van de Voort]

On 2013-03-12, JJ <jaej...@nah.meh> wrote:
> 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]

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]

On 2013-03-15, JJ <jaej...@nah.meh> wrote:
>>> 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
>
> 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?

> 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]

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]

On 2013-03-16, Jamie <jamie_ka1lpa_not_v...@charter.net> wrote:
>>
>> 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?

> 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.

> 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.

> 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]

Marco van de Voort wrote:

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]

On 2013-03-16, Jamie <jamie_ka1lpa_not_v...@charter.net> wrote:

>> 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.

> 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.

> 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.

> 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.

> 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.

> 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?

> 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.

[Rudy Velthuis (TeamB)]

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.


--
Rudy Velthuis http://www.rvelthuis.de

"The average person thinks he isn't." -- Father Larry Lorenzoni

[Marco van de Voort]

On 2013-03-16, Rudy Velthuis (TeamB) <newsg...@rvelthuis.de> 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.
>> 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:

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

[Rudy Velthuis (TeamB)]

Marco van de Voort wrote:

Hmmm... indeed.

--
Rudy Velthuis http://www.rvelthuis.de

"My opinions might have changed, but not the fact that I am
right."

[Rudy Velthuis (TeamB)]

Rudy Velthuis (TeamB) wrote:

> Marco van de Voort wrote:
>
> > On 2013-03-16, Rudy Velthuis (TeamB) <newsg...@rvelthuis.de>
> > 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.
> > >> 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:
> >
> > 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.

--
Rudy Velthuis http://www.rvelthuis.de

"Patriotism means to stand by the country. It does not mean to
stand by the president or any other public official..."
-- Theodore Roosevelt

[JJ]

Marco van de Voort <mar...@toad.stack.nl> wrote:

> 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.

> 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

[JJ]

Jamie <jamie_ka1lpa_not_v...@charter.net> wrote:
> ... 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.

[JJ]

"Rudy Velthuis (TeamB)" <newsg...@rvelthuis.de> wrote:

> 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_%28Delph
> i%29

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

> 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?

[Marco van de Voort]

On 2013-03-16, Rudy Velthuis (TeamB) <newsg...@rvelthuis.de> wrote:
>> > 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:
>> >
>> > 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....

[Marco van de Voort]

On 2013-03-17, JJ <jaej...@nah.meh> wrote:
> Marco van de Voort <mar...@toad.stack.nl> wrote:
>> 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.
>
>> Done http://pastebin.com/WcwsP7Cn
>
> Is RTTI enabled in that build or is it explicitly used in XE3? 280k is used

It's off.

> 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.

[Jamie]

You sound like a real coder!

Jamie

[Rudy Velthuis (TeamB)]

JJ wrote:

> 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.

--
Rudy Velthuis http://www.rvelthuis.de

"The best time I ever had with Joan Crawford was when I pushed
her down the stairs in 'Whatever Happened to Baby Jane?'"
-- Bette Davis

[Marco van de Voort]

On 2013-03-17, Rudy Velthuis (TeamB) <newsg...@rvelthuis.de> wrote:
>> 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.