File size and smartlinking
│
Deutsch (de) │
English (en) │
français (fr) │
日本語 (ja) │
português (pt) │
中文（中国大陆） (zh_CN) │
This article is a work in progress about executable size and smartlinking on Lazarus. Feel free to contribute.
Introduction
In Free Pascal, "smartlinking" is removing unused code and variables from the final executable. This is done during the linking stage, when the executable is written using the object files created by the compiler earlier.
Case study 1 in Windows
This study was conducted on the 8th of February 2006 because a Lazarus fully compiled with Smartlinking was Released (version 0.9.12). It intends to establish the relationship between the varying results below with different Lazarus and Free Pascal versions as well as with Smartlinking and without.
The Variables being studied are:
- Executable size after strip
- Executable size after strip and UPX
- Linking time
Compile time isn´t considered here because it´s too similar on all configurations and much less significant than the link time.
Executable size without strip isn´t included. Notice that strip was used always from command line with the command:
strip --strip-all magnifier.exe
The program being compiled is the Virtual Magnifying Glass. The source and binaries for this program are freely available for download on: http://magnifier.sourceforge.net
About the linking time please note that the utilized computer is 3.2GHz Pentium 4 with Intel motherboard and dual core processor and 512MB of RAM.
Results
The utilized OS is Windows XP and the 0.9.13 versions are from the same date when 0.9.12 was release. The comparison took place using the following software configurations:
- Lazarus 0.9.12 available here. Free Pascal 2.0.2 that comes with the installer. LCL and RTL are smartlinked. Refered from now on as simply 0.9.12.
- Lazarus 0.9.13 downloaded from Subversion from the same date. Free Pascal 2.0.2 installed separately. The LCL is not smartlinked. Refered from now on as simply 0.9.13 + 2.0.2.
- Lazarus 0.9.13 snapshot. Free Pascal 2.1 that comes with the installer. The LCL is not smartlinked. Refered from now on as simply 0.9.13 + 2.1.
- Lazarus 0.9.13 snapshot. Free Pascal 2.1 that comes with the installer. The LCL is smartlinked. Refered from now on as simply 0.9.13 + 2.1 + SL.
| 0.9.12 | 0.9.13 + 2.0.2 | 0.9.13 + 2.1 + SL | 0.9.13 + 2.1 | |
|---|---|---|---|---|
| File Size after strip (in bytes) | 1,108,480 | 1,587,712 | 1,425,408 | 1,649,152 |
| File Size after UPX (in bytes) | 318,976 | 438,272 | 388,608 | 454,144 |
| Linking time | 15 seconds | 5 seconds | 45 seconds | 10 seconds |
Conclusion
The 0.9.13 snapshot from the 8th of February 2006 features a unstable compiler from the 2.1 branch, which can cause the bigger executables and slower linking time as compared to the other versions.
The 0.9.12 version has the best file size of all, both with UPX and without, showing that Smartlinking really can diminish the file size in Windows. This, however, does not come without a cost, and the cost is linking time, which is about 3 times higher then without smartlinking.
The 0.9.12 version already comes fully configured for Smartlinking on Windows and no extra configuration is needed. This was not the case on previous releases.
Remove unused functions in a class
Q: If a virtual method of a class is not used at all in the programm will the compiler remove it from the executable ?
A: If you use FPC 2.3.1 with whole-program optimization and the compiler can prove that it is never callable: yes. See Whole Program Optimization for more information. In case this is in relation to the thread on the Lazarus list about the big executables: note that it has only a limited effect on Lazarus programs, because almost all linked LCL code can potentially be executed (due to the way the LCL is constructed). In fact, I think most savings there come from making a number of virtual method calls non-virtual, rather than from throwing away unreachable code.
The internal linker can also do it (only throwing away virtual method calls, not turning virtual method calls into static ones), but only on Windows platforms. It is however not currently enabled in the compiler, because the changes break the external linker. It should therefore be turned into a command line option (along with a check that produces an error if you try to link a unit compiled with the option using the external linker), but that hasn't been done yet.
Q: How can the compiler determine that a virtual method is unused at all,
A: If you have a class hierarchy TBase->TDerived1->TDerived2 with a virtual method called "vmethod", and nowhere in the program there is a call to vmethod, then it is unused. Or if it is only called using TDerived2 instances, then if the linker does not find any direct references to TDerived1.vmethod or TBase.vmethod (e.g., via "inherited" calls from TDerived2 methods), it knows that the VMT entries for "vmethod" in TDerived1 and TBase can be set to nil.
