public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-user] Comparatively slow clang startup vs. gcc - reasons?
@ 2018-10-09 17:55 Holger Hoffstätte
  2018-10-10  3:29 ` P Levine
  0 siblings, 1 reply; 2+ messages in thread
From: Holger Hoffstätte @ 2018-10-09 17:55 UTC (permalink / raw
  To: gentoo-user


(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



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [gentoo-user] Comparatively slow clang startup vs. gcc - reasons?
  2018-10-09 17:55 [gentoo-user] Comparatively slow clang startup vs. gcc - reasons? Holger Hoffstätte
@ 2018-10-10  3:29 ` P Levine
  0 siblings, 0 replies; 2+ messages in thread
From: P Levine @ 2018-10-10  3:29 UTC (permalink / raw
  To: gentoo-user

On Tue, Oct 9, 2018 at 1:55 PM Holger Hoffstätte
<holger@applied-asynchrony.com> wrote:
> 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
>

Has anyone tested with -DLLVM_BUILD_LLVM_DYLIB=ON and
-DLLVM_LINK_LLVM_DYLIB=ON?  It seems to be made to solve this kind of
issue.

LLVM_BUILD_LLVM_DYLIB:

If enabled, the target for building the libLLVM shared library is
added. This library contains all of LLVM’s components in a single
shared library. Defaults to OFF. This cannot be used in conjunction
with BUILD_SHARED_LIBS. Tools will only be linked to the libLLVM
shared library if LLVM_LINK_LLVM_DYLIB is also ON. The components in
the library can be customised by setting LLVM_DYLIB_COMPONENTS to a
list of the desired components.

LLVM_LINK_LLVM_DYLIB:

If enabled, tools will be linked with the libLLVM shared library.
Defaults to OFF. Setting LLVM_LINK_LLVM_DYLIB to ON also sets
LLVM_BUILD_LLVM_DYLIB to ON.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-10-10  3:29 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-10-09 17:55 [gentoo-user] Comparatively slow clang startup vs. gcc - reasons? Holger Hoffstätte
2018-10-10  3:29 ` P Levine

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox