Created attachment 9685 [details] libstdc++ build log I tried building chrome with libc++ (since we need to ship on 10.6, with a libc++ set to "all symbols hidden", and statically linked -- https://codereview.chromium.org/11468030/ see . This is research only for now.) Doing a full build of the 'chrome' target consistently takes longer with libc++ than with libstdc++ (with clang r168474). Building with libc++ takes around 38 minutes, building with libc++ takes around 31 minutes. (I built several times with both configurations, and the numbers varied by 50s. I interleaved the builds, so it's unlikely that this is explainable by some big background job taking up a huge amount of cpu). I'm attaching the .ninja_log file for both builds. The format is "start timestamp in ms, end timestamp in ms, 0, output path, hash". With that file, it should be possible to find out for which files the difference is biggest.
Created attachment 9686 [details] libc++ build log
Created attachment 9687 [details] python script Here's a small python script that prints the top 25 slower and faster targets. Here's its output: (difference in run times [ms]) (-12179, 'Chromium Framework.framework/Versions/A/Chromium Framework') (-12179, 'Chromium Framework.framework/Versions/A/Chromium Framework.TOC') (-8216, 'obj/third_party/libjingle/source/talk/session/media/libjingle_peerconnection.channel.o') (-8197, 'obj/chrome/browser/extensions/browser_extensions.extension_service.o') (-8145, 'obj/chrome/browser/automation/browser.testing_automation_provider.o') (-8094, 'obj/third_party/libjingle/source/talk/session/media/libjingle_peerconnection.call.o') (-7796, 'obj/content/browser/renderer_host/content_browser.render_process_host_impl.o') (-7674, 'obj/content/renderer/content_renderer.render_view_impl.o') (-7283, 'obj/chrome/browser/extensions/browser_extensions.extension_function_registry.o') (-6853, 'obj/third_party/libjingle/source/talk/session/media/libjingle_peerconnection.mediasession.o') (-6478, 'obj/third_party/libjingle/source/talk/app/webrtc/libjingle_peerconnection.webrtcsdp.o') (-6240, 'obj/chrome/browser/task_manager/browser.task_manager_resource_providers.o') (-6201, 'obj/third_party/libjingle/source/talk/session/media/libjingle_peerconnection.mediasessionclient.o') (-5900, 'obj/chrome/browser/browser.chrome_content_browser_client.o') (-5871, 'obj/chrome/browser/ui/browser_ui.browser.o') (-5817, 'obj/chrome/browser/profiles/browser.profile_impl.o') (-5733, 'obj/content/browser/loader/content_browser.resource_dispatcher_host_impl.o') (-5700, 'obj/chrome/browser/automation/browser.automation_provider_observers.o') (-5651, 'obj/chrome/browser/browsing_data/browser.browsing_data_remover.o') (-5539, 'obj/content/renderer/pepper/content_renderer.pepper_plugin_delegate_impl.o') (-5428, 'obj/third_party/libjingle/source/talk/media/webrtc/libjingle_peerconnection.webrtcvoiceengine.o') (-5418, 'obj/chrome/browser/profiles/browser.off_the_record_profile_impl.o') (-5395, 'obj/chrome/browser/sync/browser.profile_sync_components_factory_impl.o') (-5361, 'obj/chrome/browser/extensions/browser_extensions.event_router.o') (-5352, 'gen/tc_glibc/lib64/libbase_untrusted.a') (2763, 'libwebcore_remaining.a') (1716, 'gen/tc_newlib/lib32/libppapi_proxy_untrusted.a') (1699, 'gen/tc_newlib/lib64/libppapi_proxy_untrusted.a') (1151, 'obj/third_party/angle/src/compiler/translator_common.initialize.o') (988, 'libv8_base.a') (977, 'obj/content/common/content_common.content_message_generator.o') (924, 'gen/tc_newlib/lib64/libirt_browser.a') (804, 'gen/sdk/toolchain/mac_x86_glibc/stamp.untar') (762, 'obj/third_party/libxml/src/libxml.xmlschemas.o') (714, 'resources/inspector/DevTools.js') (698, 'gen/tc_newlib/lib32/libirt_browser.a') (677, 'gen/tc_pnacl_newlib/lib/libnacl.a') (642, 'obj/chrome/app/policy/gen/policy/policy/policy.cloud_policy_generated.o') (638, 'obj/third_party/webkit/source/webcore/rendering/webcore_rendering.rendergrid.o') (618, 'obj/third_party/webkit/source/webcore/rendering/webcore_rendering.renderfullscreen.o') (615, 'gen/webkit/webkit_chromium_resources.rc') (615, 'gen/webkit/webkit_chromium_resources.pak') (615, 'gen/webkit/grit/webkit_chromium_resources.h') (549, 'obj/third_party/webkit/source/webcore/webcore.gyp/gen/webkit/webcore_bindings.svgelementfactory.o') (545, 'pdfsqueeze') (539, 'infoplist_strings_tool') (539, 'genperf') (537, 'obj/third_party/webkit/source/webcore/rendering/webcore_rendering.renderhtmlcanvas.o') (536, 'obj/third_party/webkit/source/webcore/rendering/webcore_rendering.renderiframe.o') Linking the framework probably takes longer because an additional different static library needs to be linked; this can be ignored. Building libwebcore_remaining is probably faster with libc++ because smaller code gets generated (the chrome binary with libc++ is 700kB smaller than the libstdc++ one). Generally, there seems to be a long tail of .o files that take significantly longer to build with libc++. All these files take 40-70% longer to compile with libc++ (i.e. they aren't relatively small increases for files that already take long to compile; it's a substantial increase.)
Created attachment 9690 [details] Clang -print-stats diff for libjingle_peerconnection.channel.o with libstdc++ and libc++ There doesn't seem to be any one thing causing the difference on the Clang side: there is simply more of everything in the libc++ build. See attachment: nearly 4x as many types, 10x as many implicit special members, 2.5x as many declarations, and so on.
Created attachment 11336 [details] Compilation time comparisons
I had tested compilation time for all combinats of clang, gcc with libcxx and libstdc++ . The compiled code was short: #include <iostream> int main() { std::cout<<"hello cout\n"; return 0; } I repeated every run few times and got consistent results. The results attached. * clang is about 50% slower than gcc for all three cases. * Windows.h doubles compilation time and not required. Remove it out asap! * Even w/o windows.h, libcxx compilation time is twice the libstdc++ compilation time with either compiler. * Comparing each compiler with its own library, clang+libcxx compilation is three times as much slower as gcc+libstdc++ !!
(In reply to comment #5) > * clang is about 50% slower than gcc for all three cases. > * Windows.h doubles compilation time and not required. Remove it out asap! > * Even w/o windows.h, libcxx compilation time is twice the libstdc++ > compilation time with either compiler. > * Comparing each compiler with its own library, clang+libcxx compilation is > three times as much slower as gcc+libstdc++ !! Which gcc/libstdc++ are you comparing against?
Looks like things haven't improved much: λ clang -v clang version 3.7.0 (trunk 236946) Target: x86_64-suse-linux Thread model: posix Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/4.8 Selected GCC installation: /usr/lib64/gcc/x86_64-suse-linux/4.8 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 λ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-4.8 --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux Thread model: posix gcc version 4.8.3 20141208 [gcc-4_8-branch revision 218481] (SUSE Linux) λ cat t.cpp #include <iostream> int main() { std::cout<<"hello cout\n"; return 0; } λ time clang++ t.cpp clang++ -std=c++14 -stdlib=libc++ -fuse-ld=gold t.cpp 0.67s user 0.02s system 99% cpu 0.692 total λ time g++ t.cpp g++ t.cpp 0.09s user 0.01s system 96% cpu 0.107 total
It would be unfair to compare g++ w/ libstdc++ and clang w/ libc++. I'll look into comparing the *same* clang with both libstdc++ and libc++. However this is very low on my priority list.
(In reply to comment #8) > It would be unfair to compare g++ w/ libstdc++ and clang w/ libc++. I'll > look into comparing the *same* clang with both libstdc++ and libc++. However > this is very low on my priority list. Well thats only a 1x slowdown: λ time clang++ -std=c++11 -stdlib=libstdc++ t.cpp clang++ -std=c++14 -stdlib=libc++ -fuse-ld=gold -std=c++11 -stdlib=libstdc++ 0.29s user 0.03s system 99% cpu 0.316 total λ time clang++ -std=c++11 -stdlib=libc++ t.cpp clang++ -std=c++14 -stdlib=libc++ -fuse-ld=gold -std=c++11 -stdlib=libc++ 0.60s user 0.03s system 99% cpu 0.633 total
I don't really think that this is a bug. I think that we have been comparing different things. First, some timings that I just did. (All of these, I ran several times) $ time totclang -c -std=c++11 -stdlib=libstdc++ bug.cpp real 0m0.187s user 0m0.156s sys 0m0.025s $ time totclang -c -std=c++11 -I /Sources/LLVM/llvm/projects/libcxx/include bug.cpp real 0m0.346s user 0m0.311s sys 0m0.030s Seems pretty straightforward, right? But that's comparing libstdc++ 4.2.1, a C++03 standard library implementation, to ToT libc++ a C++11 library implementation. The C++11 standard library is much larger. So, let's compare apples to apples. Let's look at more modern libstdc++ versions - ones that implement the full C++11 standard library. (Note that libstdc++ didn't get most of the C++11 stuff until 4.8.x, and didn't really have all of it until 5.1) $ time totclang -c -std=c++11 -I /Sources/gcc/gcc-4.9.2/bin/include/ bug.cpp real 0m0.344s user 0m0.309s sys 0m0.032s $ time totclang -c -std=c++11 -I /Sources/gcc/gcc-5.1.0/bin/include/ bug.cpp real 0m0.345s user 0m0.304s sys 0m0.032s Now the difference is about 1 ms - probably less than the uncertainty in the timing. I would appreciate it if others would try this, and see if it matches my findings; but I'm tempted to close this as "works for me".
> I would appreciate it if others would try this, and see if it matches my > findings; but I'm tempted to close this as "works for me". Similar results on Linux with ToT clang and gcc 5-branch.
Closing because no one disputed my "works for me" examples in a year.