Why are executables so big?

[SomeGuy]

Hi,

during the compilation of my executables if found out, that the final
resulting exe is very large! Approximative >5 MB. Project consists only
of one single window with one lisbox object, even no code logic.
Why are the executables so big and how can i "shrink" them?
I searched for debugging symbol settings to be included with the
exe but i didnt found anything like that.

Thanks in avance

Best Regards

SomeGuy

[Anonymous]

OK, Ok, forget it, "first search the forum"!
My fault! Some other guys asked the same thing!

[marmin]

They are not so big. Stripped , they are 1.5 Mb. In a large project you will not see the difference.

Search strip, exe, executable, size. And find all the answers you will ever need.

[Phil H.]

They are not so big. Stripped , they are 1.5 Mb. In a large project you will not see the difference.

Search strip, exe, executable, size. And find all the answers you will ever need.

Actually, executables created with FPC and Lazarus are rather large compared to Delphi. There are two reasons for this. One is the amount of debug information included in the executable. This can be removed with the strip program on Intel architectures, but not on the Mac.

The second reason is that the FPC runtime and Lazarus LCL units are not compiled with smart linking. You can compile your units with smart linking with the -CX switch. This creates *.a files in addition to the *.ppu and *.o files for your units. You can then link your executable smart with the -XX switch. However, this only helps with units that were compiled with -CX. The Laz files were not, so you're still linking in a lot of compiled runtime and LCL code that your program doesn't need.

I'm not sure why Laz isn't distributed with the *.a files too. Perhaps it's to keep the size of the download to a minimum.

In general, with small to medium sized projects, the amount of your code is dwarfed by the amount of code linked in from the runtime and LCL units, so you won't see much benefit from the -CX and -XX switches, unless you have a great deal of unused routines (for example, in a large library of routines) that you're not referencing in your program.

Perhaps a better indicator of program size than executable file size or amount of code generated is run-time memory footprint. For example, with one of my projects consisting of about 100,000 lines of code, when compiled with Delphi 7, the Windows Task Manager shows the program has a memory footprint of about 8.1MB. The same code compiled with the latest Lazarus snapshot shows a footprint when run of about 9.5MB. In general, footprint size is affected by code size, unit granularity, and memory use.

Is this difference significant on a system with 512MB or more of RAM? Probably not. I would expect the footprint to come down a bit when linked with runtime and LCL units that have been compiled with the -CX switch.

Having said that, it seems as though this issue should be addressed better in Lazarus, even if only in documenting better what our options are. This is probably the most frequently asked question on this forum - in fact, I believe this is the first question I asked when I started using Lazarus.

-Phil