1 |
(paging Michał Górny..) |
2 |
|
3 |
I've noticed that clang has gotten really slow, and while it does |
4 |
great analysis during the various compilation stages (which is fine), |
5 |
the startup itself is a major contributor to perceived slowness. |
6 |
|
7 |
Nothing demonstrates this better than running ./configure in a random |
8 |
project - here nghttp2: |
9 |
|
10 |
$time ./configure |
11 |
./configure 5.83s user 1.10s system 100% cpu 6.866 total |
12 |
./configure 5.73s user 1.04s system 101% cpu 6.669 total |
13 |
./configure 5.74s user 1.04s system 101% cpu 6.671 total |
14 |
|
15 |
$time ./configure CC=clang CXX=clang++ |
16 |
./configure CC=clang CXX=clang++ 21.43s user 2.56s system 99% cpu 24.011 total |
17 |
./configure CC=clang CXX=clang++ 21.37s user 2.61s system 100% cpu 23.911 total |
18 |
./configure CC=clang CXX=clang++ 21.56s user 2.51s system 100% cpu 23.995 total |
19 |
|
20 |
That's almost 3 times slower doing not much at all. |
21 |
|
22 |
A major contributor to this is the relatively large number of shared |
23 |
objects being loaded as a consequence of building llvm with shared objects, |
24 |
incurring large relocation costs compared to short-lived runs. |
25 |
gcc on the other hand consists of mostly-monolithic binaries, minus the |
26 |
few usual suspects like zlib etc. |
27 |
|
28 |
A brief run with "perf record" compiling helloworld.c and comparing |
29 |
the "perf report" output between gcc and clang confirms that clang |
30 |
spends the vast majority of its time in ld.so. |
31 |
|
32 |
Can we do something about this? I remember that llvm had optional static |
33 |
libs, which apparently were removed completely. Is there something |
34 |
that can be done with linker tricks (better relocation info?) when |
35 |
building llvm/clang to speed up the .so loading? |
36 |
|
37 |
curious, |
38 |
Holger |