ENORMOUS executables

[euthymos]

Go away already

Yes, sir.  :wink:

[Legolas]

I rebuilt LCL with -XX -Xs -CX options enabled. I've got executables 60% smaller. A single-form "hello world" application takes only 293 KB if stripped and compressed.

Side effects of the rebuild? Never mind. I use two different installs of lazarus, one for the debug and one for optimization.

I (the troll) found a solution which is a horrible hack but works quite well. You should add it into the FAQs.

Good! Perhaps you finally have found the "search" button?

[felipemdc]

Side effects of the rebuild? Never mind. I use two different installs of lazarus, one for the debug and one for optimization.

I (the troll) found a solution which is a horrible hack but works quite well. You should add it into the FAQs.

This is already well documented:

http://wiki.lazarus.freepascal.org/index.php/File_size_and_smartlinking

I didn't mention it before because of the side effects, like increased linking time (which you solved by having 2 installs). Maybe I should have mentioned?
 

[euthymos]

http://wiki.lazarus.freepascal.org/index.php/File_size_and_smartlinking

This is not a topmost wiki article, while it should be.
However, you gave up because of too long linking times. I can understand it.

Maybe I should have mentioned?

Maybe you should. That solution is the only one effective, but nobody talks about it. Side effects, like I said before, are not a problem: you can use, in the same machine, two different builds of Lazarus, one for testing and debugging, one for compiling the final release. ~200KB for a single empty form is quite good. Now I can use Lazarus for my interoperable applications.

Tell the ignorant folks (like me) about smartlinked LCL. They'll appreciate it more than people who cloak problems with a couple of grunts (which is not you, sekel).

[Phil (not logged in)]

Tell the ignorant folks (like me) about smartlinked LCL.

If you're working with Lazarus on Windows, you might try some real-world tests on your own code by compiling from a batch file rather than the IDE and do the following 3 things:

- Don't use -gl switch with FPC.
- Use the new internal linker (-Xi switch).
- Use the -vx switch so the compiler displays the amount of code generated (like Delphi does).

Here's my results:

Example 1. Console app, over 20,000 lines of code:

Delphi 7: Compile and link time: Less than 1 sec.
FPC: Compile and link time: About 2 secs. Link only: 0.5 sec. [These are huge improvements over the external GNU linker.]

Delphi 7 code: 260K
FPC code: 304K

Delphi 7 .exe: 286K
FPC .exe: 296K

[When zipped (to simulate the way software is distributed) the difference in file size is only about 25K.]

No hacks, no rebuilding of Laz, no strip, no UPX, just using FPC properly.

Example 2: GUI app, over 100,000 lines of code.

Delphi 7: Compile and link time: less than 1 sec.
FPC: Compile and link time: 6 secs. Link only: Only 2 secs!

Delphi 7 code: 1,220K
FPC code: 1,549K

Delphi 7 .exe size: 1,554,432
FPC .exe size: 2,248,300

What can be concluded from these examples?

(1) It's not really a problem with the compiler, but with the external linker. If the internal linker becomes available for all platforms, speed and code size will be improved dramatically overnight.

(2) Since LCL is structured differently (multiple layers) than Delphi's VCL in order to be cross-platform, it shouldn't be surprising that more code gets dragged into the app. Offhand it looks like an LCL app adds about 200-300K more code (not .exe file size) over VCL. With non-trivial apps, this doesn't strike me as anything to worry about.

(3) Perhaps a better measure than code or .exe size would be the memory footprint of the app. FPC compares fairly well here too:

Example 2 above, started but no other activities performed by user:

Delphi 7 version: 5,652K footprint (according to Task Manager)
FPC version: 6,952K footprint

So about 1.3MB larger memory footprint for the LCL app. It's hard to say exactly what causes the difference since so many things can affect an app's memory use, but on my machine I have 1 GB RAM so this difference again seems almost trivial.

Compare the results above with, say, a good sized app compiled with GCC (GNU Compiler Collection), where compile and link times are so slow that you can get in a nap between builds.

[euthymos]

Tell the ignorant folks (like me) about smartlinked LCL.

- Use the new internal linker (-Xi switch).

Internal linker? I didn't know.

[felipemdc]

Internal linker? I didn't know.

Yes. On most platform we use the GNU Linker (which has all those problems you already know, like huge linking time, etc.

So a internal linker (much better then GNU Linker) was developed. As a effect of that, we now support Windows 64, while gcc for example still doesn't.

The problem is that it's only available on the development branch of the compiler (2.1.1 version), so I don't recommend using it for someone new to Lazarus.

[euthymos]

The problem is that it's only available on the development branch of the compiler (2.1.1 version), so I don't recommend using it for someone new to Lazarus.

However it is a great news. The ignorant is waiting for the release  

[Phil]

Tell the ignorant folks (like me) about smartlinked LCL.

- Use the new internal linker (-Xi switch).

Internal linker? I didn't know.

Run FPC from the command line to see all the switches. -Xi is listed under the executable options.

At least one typo in my results above. In example 1, the FPC .exe was 396K, not 296K. The comments in [] that follow make no sense as written with the given file sizes.

[BeniBela]

Will there be an internal debugger in the future, too?
I think this would be usefull, because then the debugger can get the debug information direct from the linker, without storing them in the exe. (probably the one of Delphi works this way)
Thus a smaller exe will be created faster.

[Vincent Snijders]

The internal linker is internal to the compiler (not the IDE). A similar internal debugger would be useless, since the compiler doesn't execute code.

[Anonymous]

If you go to 'Linking' tab of Project/CompilerOptions, you should swithch off the 'Display line numbers in Run-time Error Backtraces'. This should dramatically reduce the size of your executable. A bare windows executable is 1.8Mb before stripping and UPX, and 513kb after (using the latest 0.9.17 SVN). The latest builds of Lazarus are really impressive - this project has gone a long way in the last year.

[BeniBela]

The main idea of my previous post is about giving the debugger all necessary information over the memory, if it is internal to the ide, the compiler (well, there you're right, that would be a little bit strange) or even a modified gdb shouldn't matter.
But problably there are other things which are much more important than that, so noone has time to work on it.

[bruyere]

une solution
metttre dans :
projet->option du compilateur->compilation->exécuter aprés
strip --strip-all 'myprogram'

fonction teste sous linux (mandriva10.0 et lazarus 9.18  )
avant 7.8M
aprés 2.7M avec cette option.
il y peut etre mieux :idea:

[Chen]

OK. Apparently, we have different ideas about programming.

I want the size of the executable to be consistent with the useful stuff that is inside. The program: "program helloworld; begin end." cannot take 253 KB. This is a record, you should apply for Guinness Book...

It's a problem of mine, I've got to be more flexible.

Im new to lazarus but I want so say Im worry too because the executable sizes..

I read several things here in the forums, and modifying parameters and using UPX the executables went from 6.5 MB to 436KB in Windows and from
6.5MB to 568KB in Ubuntu, and for me is something big...

I use  PureBasic to develop app's, it is  WIndows-Linux crossplatform in 99%.
If you want to use Windows API...  you need to go with GTK  equivalents....
but you can create working app's without API.  Use API for specialized things
like games if you go with DirectX and things like that...
PureBasic for MAC OSX is in Beta with the croosplatform goal alive....

PureBasic 100% crossplatform (without API), Windows-Linux-Mac and does not
have this problem... the small app start with 5K in any platform... sizes over
100K means real applications.

Hope Lazarus team come out in the future with some ideas so we can see
small executables.

Anyway is only a comment...  Lazarus looks great and can be the other
option....