From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 8385A138334 for ; Tue, 9 Oct 2018 17:58:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D0EC4E0824; Tue, 9 Oct 2018 17:58:13 +0000 (UTC) Received: from blaine.gmane.org (unknown [195.159.176.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 588DFE07E2 for ; Tue, 9 Oct 2018 17:58:13 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1g9wEg-0005EW-NF for gentoo-user@lists.gentoo.org; Tue, 09 Oct 2018 19:55:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Holger =?iso-8859-1?q?Hoffst=E4tte?= Subject: [gentoo-user] Comparatively slow clang startup vs. gcc - reasons? Date: Tue, 9 Oct 2018 17:55:52 +0000 (UTC) Message-ID: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@blaine.gmane.org User-Agent: Pan/0.145 (Duplicitous mercenary valetism; d7e168a git.gnome.org/pan2) X-Archives-Salt: 91370dcb-216e-4a52-a2fd-9b6b39c70473 X-Archives-Hash: b191cba5ee695c23fe308dd51584d078 (paging Michał Górny..) I've noticed that clang has gotten really slow, and while it does great analysis during the various compilation stages (which is fine), the startup itself is a major contributor to perceived slowness. Nothing demonstrates this better than running ./configure in a random project - here nghttp2: $time ./configure ./configure 5.83s user 1.10s system 100% cpu 6.866 total ./configure 5.73s user 1.04s system 101% cpu 6.669 total ./configure 5.74s user 1.04s system 101% cpu 6.671 total $time ./configure CC=clang CXX=clang++ ./configure CC=clang CXX=clang++ 21.43s user 2.56s system 99% cpu 24.011 total ./configure CC=clang CXX=clang++ 21.37s user 2.61s system 100% cpu 23.911 total ./configure CC=clang CXX=clang++ 21.56s user 2.51s system 100% cpu 23.995 total That's almost 3 times slower doing not much at all. A major contributor to this is the relatively large number of shared objects being loaded as a consequence of building llvm with shared objects, incurring large relocation costs compared to short-lived runs. gcc on the other hand consists of mostly-monolithic binaries, minus the few usual suspects like zlib etc. A brief run with "perf record" compiling helloworld.c and comparing the "perf report" output between gcc and clang confirms that clang spends the vast majority of its time in ld.so. Can we do something about this? I remember that llvm had optional static libs, which apparently were removed completely. Is there something that can be done with linker tricks (better relocation info?) when building llvm/clang to speed up the .so loading? curious, Holger