Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2005-05

Executable size compiler 1.96 vs 1.06

16 messages · 4 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

L505

With compiler version 1.96, one of my command line applications is 1MB (win32) With the 1.0.6 compiler (using dev pascal) it is just 100KB. (win32)

On linux, 1.96 the application was about 300KB.
(not so worried about linux, since this is not consistent testing..comparing two OS's)

What is the major reason for the different sizes? The application I'm testing uses the same compiler command line arguments. The application calls on the synregexpr unit (which calls for the classes unit). I'm guessing the classes unit maybe has something to do with the size addition. But how come 100KB to 1MB? This reminds me of when I first started using lazarus and comparing to Delphi, or when I first started using KOL vs VCL in Delphi ;-)

Before I go digging into the sources spending hours figuring out the major code changes between the compilers, maybe you could just give me a summary of the major causes (the compiler was completely rewritten, with this much difference?)
Also, if there is discussion on this in the mailing list from previous questioners let me know! I just want to know some of the details (like it's because of more initialization functions? because the classes unit got bigger with time? code that just couldn't be smart linked in later compiler versions?).

Lars

Reply by email

Peter Vreman
to L505
Show quoted text 29 lines
With compiler version 1.96, one of my command line applications is 1MB (win32) With the 1.0.6 compiler (using dev pascal) it is just 100KB. (win32) On linux, 1.96 the application was about 300KB. (not so worried about linux, since this is not consistent testing..comparing two OS's) What is the major reason for the different sizes? The application I'm testing uses the same compiler command line arguments. The application calls on the synregexpr unit (which calls for the classes unit). I'm guessing the classes unit maybe has something to do with the size addition. But how come 100KB to 1MB? This reminds me of when I first started using lazarus and comparing to Delphi, or when I first started using KOL vs VCL in Delphi ;-) Before I go digging into the sources spending hours figuring out the major code changes between the compilers, maybe you could just give me a summary of the major causes (the compiler was completely rewritten, with this much difference?) Also, if there is discussion on this in the mailing list from previous questioners let me know! I just want to know some of the details (like it's because of more initialization functions? because the classes unit got bigger with time? code that just couldn't be smart linked in later compiler versions?).

Initialization of the classes and implicitly used sysutils unit uses more code. Also the use of resourcestrings increases the binary.

The size is mainly a rtl issue. The smartlinking principle in the compiler isn't changed since 1.0.6.

Reply by email

Marco van de Voort
to Peter Vreman
Show quoted text 9 lines
> With compiler version 1.96, one of my command line applications is 1MB > (win32) > With the 1.0.6 compiler (using dev pascal) it is just 100KB. (win32) Initialization of the classes and implicitly used sysutils unit uses more code. Also the use of resourcestrings increases the binary. The size is mainly a rtl issue. The smartlinking principle in the compiler isn't changed since 1.0.6.

Moreover is it stripped and smartlinked?

Reply by email

Tomas Hajny
to L505: With compiler version 1.96, one of my command line applications is 1MB (win32) With the…

Date sent: Mon, 16 May 2005 22:03:28 -0700
From: L505
To: FPC-Pascal users discussions
Subject: [fpc-pascal] Executable size compiler 1.96 vs 1.06 Send reply to: FPC-Pascal users discussions

With compiler version 1.96, one of my command line applications is 1MB (win32) With the 1.0.6 compiler (using dev pascal) it is just 100KB. (win32)

.
.

In spite of the fact that there _is_ some code size increase in 2.0.x compared to 1.0.x (due to additional functionality - multi-threading, etc.), your problem stems most probably in the fact that recent released versions of GNU tools (ld.exe in particular) don't correctly strip the debug information. The latest GNU sources could solve this issue. Please, note that it isn't a problem in our codebase, so there's a little we can do about that. The next version should hopefully contain a newer (fixed) version of these tools.

Tomas

Reply by email

Peter Vreman
to L505: | | Initialization of the classes and implicitly used sysutils unit uses more | code.…
Show quoted text 18 lines
| | Initialization of the classes and implicitly used sysutils unit uses more | code. Also the use of resourcestrings increases the binary. | | The size is mainly a rtl issue. The smartlinking principle in the compiler | isn't changed since 1.0.6. | Hmm, so really then I shouldn't notice that huge difference, because I have smart linking on (both smartlinking options checked, using lazarus IDE for win32). But I'm going to run a fresh command line compile now, just incase some setting is mucked up somewhere or a misconfigured cfg file is somehow being called.

Please test it with a official FPC 2.0.0 win32 release. The size should be less. A simple hello world is only 25KB. And a hello world+classes unit is 130KB.

Reply by email

L505
to Peter Vreman: Initialization of the classes and implicitly used sysutils unit uses more code. Also the…

|
| Initialization of the classes and implicitly used sysutils unit uses more | code. Also the use of resourcestrings increases the binary. |
| The size is mainly a rtl issue. The smartlinking principle in the compiler | isn't changed since 1.0.6.
|

Hmm, so really then I shouldn't notice that huge difference, because I have smart linking on (both smartlinking options checked, using lazarus IDE for win32). But I'm going to run a fresh command line compile now, just incase some setting is mucked up somewhere or a misconfigured cfg file is somehow being called.

Reply by email

L505
to Tomas Hajny: Date sent: Mon, 16 May 2005 22:03:28 -0700 From: L505 To: …

|
| In spite of the fact that there _is_ some code size increase in 2.0.x | compared to 1.0.x (due to additional functionality - multi-threading, | etc.), your problem stems most probably in the fact that recent | released versions of GNU tools (ld.exe in particular) don't correctly | strip the debug information. The latest GNU sources could solve this | issue. Please, note that it isn't a problem in our codebase, so | there's a little we can do about that. The next version should | hopefully contain a newer (fixed) version of these tools. |
| Tomas
|

Ahh.. I'm looking forward to this then... surely this is part or all of the problem then.. Ok, so off to sourceforge now, or wherever I google this latest CVS.

Reply by email

L505
to Marco van de Voort: Moreover is it stripped and smartlinked?

| > > With compiler version 1.96, one of my command line applications is 1MB | > > (win32)
| > > With the 1.0.6 compiler (using dev pascal) it is just 100KB. (win32) |
| > Initialization of the classes and implicitly used sysutils unit uses more | > code. Also the use of resourcestrings increases the binary. | >
| > The size is mainly a rtl issue. The smartlinking principle in the compiler | > isn't changed since 1.0.6.
|
| Moreover is it stripped and smartlinked?

It is according to lazarus IDE options (smartlink checkboxes and strip checkbox).. but I will do a fresh command line compile from a different, fresh directory, just in case.

Reply by email

Marco van de Voort
to L505: Ok something I just did was: Copy ldw.exe from the \dev-pascal\bin directory over to…
Ok something I just did was: Copy ldw.exe from the \dev-pascal\bin directory over to ld.exe in the 1.9.6 compiler (rename ldw to ld) Now program is only 440kb .. hmm

This is the stripping issue I think, and depends on GNU ld.

However the old ld had some problems too, that's why was decided to ship the newer one, since one can always manually strip a release build with "strip file"

Reply by email

Peter Vreman
to Marco van de Voort
Show quoted text 12 lines
> Ok something I just did was: > Copy ldw.exe from the \dev-pascal\bin directory over to ld.exe in the > 1.9.6 compiler (rename ldw to ld) > > Now program is only 440kb .. hmm This is the stripping issue I think, and depends on GNU ld. However the old ld had some problems too, that's why was decided to ship the newer one, since one can always manually strip a release build with "strip file"

Correct. I did a test here. Lazarus provides units compiled with debug info. The new ld.exe/strip.exe has problems with stripping it. Result is a large, but working, executable.

Shipping the old ld.exe (from 1.0.x) is not an option since it can't link with current cygwin libraries. Those libraries are used to include debugger support the textmode IDE.

So it was a trade-off. Ship a working ld.exe that fails to strip .stabs or ship a ld.exe that can't link cygwin applications.

Reply by email

Marco van de Voort
to Peter Vreman

y> > the newer one,

Show quoted text 13 lines
> since one can always manually strip a release build with "strip file" > Correct. I did a test here. Lazarus provides units compiled with debug info. The new ld.exe/strip.exe has problems with stripping it. Result is a large, but working, executable. Shipping the old ld.exe (from 1.0.x) is not an option since it can't link with current cygwin libraries. Those libraries are used to include debugger support the textmode IDE. So it was a trade-off. Ship a working ld.exe that fails to strip .stabs or ship a ld.exe that can't link cygwin applications.

There is an ever newer set:

http://www.stack.nl/~marcov/mingwbinutils200501.zip

which fixed some more problems with crossbuilding from windows to linux.

Reply by email

L505
to Peter Vreman: Please test it with a official FPC 2.0.0 win32 release. The size should be less. A simple…

Ok something I just did was:
Copy ldw.exe from the \dev-pascal\bin directory over to ld.exe in the 1.9.6 compiler (rename ldw to ld)

Now program is only 440kb .. hmm

Some more testing I will do with 2.0 release.

Lars

Earlier message 36 lines
----- Original Message ----- From: "Peter Vreman" To: "FPC-Pascal users discussions" Sent: Tuesday, May 17, 2005 12:50 AM Subject: Re: [fpc-pascal] Executable size compiler 1.96 vs 1.06 | > | > | | > | Initialization of the classes and implicitly used sysutils unit uses | > more | > | code. Also the use of resourcestrings increases the binary. | > | | > | The size is mainly a rtl issue. The smartlinking principle in the | > compiler | > | isn't changed since 1.0.6. | > | | > | > Hmm, so really then I shouldn't notice that huge difference, because I | > have smart linking on (both | > smartlinking options checked, using lazarus IDE for win32). But I'm going | > to run a fresh command line compile | > now, just incase some setting is mucked up somewhere or a misconfigured | > cfg file is somehow being called. | > | | Please test it with a official FPC 2.0.0 win32 release. The size should be | less. A simple hello world is only 25KB. And a hello world+classes unit is | 130KB. | | | | | _______________________________________________ | fpc-pascal maillist - | http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Reply by email

L505
to Marco van de Voort: Try to simple do "strip xxx.exe" on the commandline

| >
| >
| > Ahh.. I'm looking forward to this then... surely this is part or all of the problem then.. Ok, so off to | > sourceforge now, or wherever I google this latest CVS. |
| Try to simple do "strip xxx.exe" on the commandline |

That worked too, now down to 440KB. Well, 2.0.0 should solve problems since the linker is funny in the lazarus FPC compiler I have .. I'm downloading it now, 70 percent of 23MB done :P

p.s. if this is the case with lazarus, should they be notified of this? if they are currently shipping this funny LD with their lazarus download?

Reply by email