[Webkit-unassigned] [Bug 102827] [CMake] Optimize binary size by removing dead sections on unix/gcc

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=102827





--- Comment #6 from Laszlo Gombos <laszlo.gombos at webkit.org>  2012-11-24 16:35:38 PST ---
(In reply to comment #3)
> (From update of attachment 175257 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=175257&action=review

> With regard to the compiler flags, gcc's man page says:
> 
>            Only use these options when there are significant benefits from
>            doing so. 

>From my experience this optimization usually carries significant benefit for large projects where there is potential for dead symbols and where binary size matters. In case of WebKit EFL port I think that ~ 2Mb binary size saving is a significant benefit. 

>From other WebKit ports the chromium port (see http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi) and Qt port (see http://trac.webkit.org/browser/trunk/Source/WebCore/WebCore.pri) have the same optimization turned on.

Mozilla has it enabled as well - http://hg.mozilla.org/mozilla-central/file/f42a83257653/build/autoconf/compiler-opts.m4.

> When you specify these options, the assembler and linker
>            will create larger object and executable files and will also be
>            slower.

I ran some performance benchmarks (sunspider, v8, dromaeo DOM core tests) and have not been able to observe a difference in execution speed and memory usage (these tests fluctuate quite a bit and the results were always in the same range). If you can think of a particular case where you expect a regression, please let us know and we should try to test it as I certainly could not test it all.

I was also expecting an increased build/linking time, but at least for incremental linking I could not find an evidence of that (only tried with gold).

> You will not be able to use "gprof" on all systems if you specify this option

This is a valid point and we should be able to work around it in the build system (like the other projects did). See also the related discussion about the precendence of user specified build options.

> and [...] you may have problems with debugging if you
>            specify both this option and -g.

I see no compelling reason to turn this on for debug builds. I will change the patch to only enable the flag for release builds.

> This sounds quite alarming; what if you just change the linker flags?

These flags should really go hand in hand - this is probably one reason why it is not the default in gcc. The saving in size for the linker-flags-only build is only about 236kB.

> Is there much difference if you compare gold and ld?

Not much. Gold saves 28kB more.

> With my packager hat on, when a program uses unusual compiler or linker flags by default it tends to trigger my spider-sense; is there any trade-off we're not aware of when enabling these flags?

I agree that as most compiler flags this is probably also a trade-off. In WebKit most of the really hot code is already optimized (e.g. JIT). In addition to these new flags in the patch the build system for EFL uses -O3 (which the CMake default) which makes performance a preference over binary size so in this combination of flags I could not demonstrate any performance difference for WebKit.

I would recommend to use these flags in any production environment - and becase of that I think we should also have it set in the buildbot so that it is tested. If some distribution/packager decides that this is not what they want they can just overrule it using environment variables. To disable these options one can use the following build command (I tested it):

build-webkit --efl --cmakearg="-DCMAKE_C_FLAGS='-fno-function-sections -fno-data-sections' -DCMAKE_CXX_FLAGS='-fno-function-sections -fno-data-sections' -DCMAKE_SHARED_LINKER_FLAGS='-Wl,--no-gc-sections'"

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.