Currently, the Projucer project uses link-time code generation, which makes building the Projucer VERY slow (on Windows, using MSVC).
I don’t think there is anything performance relevant in Projucer that would benefit from this setting, so turning it off would reduce the build-time of the Projucer significantly without introducing any side effects or causing other problems.
Even for most plugins / apps this setting doesn’t do much (if anything at all that hasn’t already been achieved with traditional inlining) so we turned it of for Nexus and our build times have so much faster as a result.
It’s very application specific. If you have lots of communication between different compilation units then a typical speedup for those bits would be something like 20%. For a standard JUCE app or plug-in, with all of the heavy lifting done in a single compilation unit, it won’t make much difference.
ThinLTO in LLVM has pretty good value though, even on big projects. Pretty much as good as the full LTO in terms of performance gains, but orders of a magnitude faster.
I would also echo the sentiment that it’s not even generally useful to have it on by default for each project that the Projucer itself generates. I always have to turn it off when I didn’t remember to turn it off when setting up a project. LTO just increases build times. Is there any evidence where it actually makes a measurable difference at runtime for a typical Juce based project?
+1 for turning it off for the Projucer. The difference it can make depends on how the compile units are structured and in the case of Projucer there is very little to gain and the increase build time is not worth it. If it makes a big difference in other projects it probably means that things are in different compile units that should be in the same one so inlining could be used which allows for even more optimizations than LTO.
