You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
object files generated by clang tend to take ~20% longer to link than the ones generated by gcc, due to chubby/different debug information.
I did incremental builds (touch one file, measure rebuild time – this measures almost exclusively ld time) of the chrome binary in several scenarios. In debug builds, the object files generated by clang take up to 6 seconds longer to link into a final binary (36s instead of 30s, or in with a shared library build, 31s instead of 27s). In release builds, there's no big difference.
So while compiling with clang is faster, linking the resulting object files currently takes longer.
Raw numbers (each is the min of 3 runs):
Chrome incremental build times (ninja, gold on by default, debug
builds, gcc4.4, chromeclang)
gcc
touch file in net (net/base/mime_util.cc) 29.4s
touch file in browser (c/b/u/g/chrome_gtk_frame.cc) 32.8s
clang
touch file in net 35.9s
touch file in browser 36.3s
gcc component build (libv8.so instead of libv8.a etc)
touch file in net 26.5s
touch file in browser 8.7s
clang component build
touch file in net 30.8s
touch file in browser 10.6s
(release builds)
gcc
touch file in net 6.4s
touch file in browser 5.9s
clang
touch file in net 6.3s
touch file in browser 6.2s
gcc component
touch file in net 6.7s
touch file in browser 3.1s
clang component
touch file in net 6.6s
touch file in browser 3.2s
The text was updated successfully, but these errors were encountered:
See also the discussion on bug 7554. That bug's been marked fixed after nlewycky's debug information improvements, but I'm not sure if all the suggested improvements over there have been implemented (cfi sections etc).
Extended Description
object files generated by clang tend to take ~20% longer to link than the ones generated by gcc, due to chubby/different debug information.
I did incremental builds (touch one file, measure rebuild time – this measures almost exclusively ld time) of the chrome binary in several scenarios. In debug builds, the object files generated by clang take up to 6 seconds longer to link into a final binary (36s instead of 30s, or in with a shared library build, 31s instead of 27s). In release builds, there's no big difference.
So while compiling with clang is faster, linking the resulting object files currently takes longer.
Raw numbers (each is the min of 3 runs):
Chrome incremental build times (ninja, gold on by default, debug
builds, gcc4.4, chromeclang)
gcc
touch file in net (net/base/mime_util.cc) 29.4s
touch file in browser (c/b/u/g/chrome_gtk_frame.cc) 32.8s
clang
touch file in net 35.9s
touch file in browser 36.3s
gcc component build (libv8.so instead of libv8.a etc)
touch file in net 26.5s
touch file in browser 8.7s
clang component build
touch file in net 30.8s
touch file in browser 10.6s
(release builds)
gcc
touch file in net 6.4s
touch file in browser 5.9s
clang
touch file in net 6.3s
touch file in browser 6.2s
gcc component
touch file in net 6.7s
touch file in browser 3.1s
clang component
touch file in net 6.6s
touch file in browser 3.2s
The text was updated successfully, but these errors were encountered: