results of using LTO Link time optimization .

Libreoffice writer 25.8.2.2 compiled without LTO has a virtual size of 1007 MB and resident size of 579 MB
Libreoffice writer 25.8.3.2 compiled WITH LTO has a virtual size of 789 M and resident memory size of 447 MB

so about 22 -23 % of the size of program in memory is removed. by only loading a shared object once.
 
1. Check your compiler’s documentation, it will be something like adding -flto. BSD make may also have a variable to enable it.

2. Disadvantages. It can greatly increase build times. It can make debugging significantly more difficult.

3. See point 2. In my experience it does not give a measurable performance gain, but I guess that ymmv for that.
 
2. Disadvantages. It can greatly increase build times. It can make debugging significantly more difficult.

a. Build times: it can be mitigated by using a different linker than default (both gcc and clang use a single-threaded linker), for example: devel/mold.
b. Debugging: I think it isn't true anymore. First versions of lto generated code in gcc was almost impossible to debug. Today it works for me without any issues. At least with newest versions of GCC. ;)

Another reason why it is disabled: as far I remember, lto was tested and works only on several platforms (i386, amd64, arm64). Also, sometimes it causes problems during cross-compiling.
 
LTO has been a compile time option for Rust compiler , firefox , thunderbird , libreoffice and others for a while now , years ?
For some versions of source code it has worked for others it failed.
Its plesant when the compile time LTO process is multithreded and a pain ( takes long time ) if its single threaded. ( you see the linker , ld, taking forever.

Its ofcourse a non-issue if you install pre-built binaries from FreeBsd repository , but interesting when you compile you own code.

View: https://www.youtube.com/watch?v=p9nH2vZ2mNo


this talk by the developer is illuminating
 
Back
Top