Fragen? Antworten! Siehe auch: Alternativlos
$ echo "int main() { return 0; }" > t.c
$ time gcc -o t t.c
gcc -o t t.c 0.03s user 0.01s system 31% cpu 0.122 total
$ time gcc -o t t.c
gcc -o t t.c 0.02s user 0.01s system 92% cpu 0.036 total
$ time clang -o t t.c
clang -o t t.c 0.19s user 0.02s system 56% cpu 0.372 total
$ time clang -o t t.c
clang -o t t.c 0.23s user 0.01s system 99% cpu 0.243 total
Das ist besonders auffällig, wenn ich meine Libraries kompiliere, die immer aus vielen kleinen Fitzeldateien bestehen. Einmal libowfat mit gcc bauen dauert 10 Sekunden, mit clang dauert es 1 Minute 25 Sekunden. WTF? Auf der selben Hardware, versteht sicht, mit allen Dateien im Cache. Und gcc ist noch "ineffizient". Bei gcc gibt es gcc, das Frontend, dann cc1, das Backend, dann as, den Assembler, dann collect2, den Wrapper um den Linker, dann ld, den Linker. Bei clang gibt es clang und ld. Wie kann denn das bitte so viel langsamer sein?!
Gut, das ist mit -O2. Vielleicht ist der Optimizer so lahm bei clang? Probieren wir mal mit -O0. gcc: 7 Sekunden. clang: *waaaaart* *kaffeehol* 1 Minute 22. Was zur Hölle?!?
clang ist von LLVM 3.7, gcc ist 5.2.0. Plattform ist Linux/AMD64.
Da tun mir ja fast ein bisschen die BSDler leid, die aus fundamentalistisch-politischen Gründen von ihrer Distro zu so einem Lahmarsch-Compiler migriert wurden.
Bei C++ ist das übrigens anders herum, da ist clang dann schneller. Aber soll ich was sagen? Es gibt da draußen viel mehr kleine C-Fitzeldateien als große C++-Monster.
Spannenderweise ist der bleeding-edge-clang++ aus dem SVN plötzlich Faktor 10 langsamer als g++. Da muss wohl irgendwas schiefgelaufen sein.
Update: Ich habe eine Theorie, wieso clang so hohe Startup-Kosten hat. Ich habe beim Bauen Shared Libraries aktiviert. Daher lädt clang bei mir beim Start gefühlte 100 Libraries rein. Das kostet halt.
Update: Und die SVN-Version hab ich versehentlich nicht auf Release-Mode gesetzt beim Bauen, deshalb ist die so lahm.
Update: Wenn ich die SVN-Version im Release-Modus und statisch gelinkt baue, dann ist der tatsächlich geringfügig schneller als gcc. Ich ziehe also alles zurück und behaupte das Gegenteil.